Offline access - SQLite or Indexed DB?

后端 未结 8 1298
一生所求
一生所求 2020-12-14 01:39

I am in the R&D phase of developing an application, with the following key requirements:

  • HTML5 web application - which will also have a hybrid version
相关标签:
8条回答
  • 2020-12-14 02:17

    I wanted to make a small edit to update this question, as google is directing to us to this question if you make a research on the subject of websql, localStorage and indexedDB. The edit was rejected, so I'm posting as a answer.

    As others stated in their answers, IndexedDB lacked a bit before on support and on content on the web for it's documentation and specification.

    But IndexedDB support has been vastly improved for mobile. It improved so much that the only browser who has no support or whatsoever, is Opera Mini, but it has only 0,34% of market usage.

    As of 2015, I would suggest any developer to move to IndexedDB, as WebSQL has been deprecated and IE and Firefox stopped supporting it (that's more than 15% of market usage for these alone!) and SQLite is losing space rapidly to IndexedDB, which have now really good documentation sources, many. Some official as well!. Some IT companies are even motivating usage as well, like IBM.

    I'm going to use it, and I have not met any problems so far. Safari has added support to it, and all major browsers as well. Go for it!

    EDIT: A personnal addendum: I tried IndexedDB. I'm a Senior on my team, and IndexedDB syntax is just too messy and complex for small storage problems - I ended using localstorage to save some simple JSON data and parsing it when I need it. Way better for anyone on my team to get it (Me as well, of course!)

    0 讨论(0)
  • 2020-12-14 02:19

    As other have pointed out, since this question has been asked, webSQL has been deprecated, while IndexedDB implementations now exist in all of the major browser vendors.

    So to anyone who may find themselves here faced with the same decision to make, go with IndexedDB.

    Others here have also implied, correctly, that a choice doesn't have to be made between the two types of databases. One can simply choose (or make) a library which utilizes whichever database is available on a client machine.

    Check out BakedGoods if you're looking for such a library. It establishes a uniform interface that can be used to conduct storage operations in all native, and some non-native client storage facilities. It also maintains the flexibility and options afforded to the user by each.

    With it, conducting storage operations in whichever of the database types is supported is a matter of...

    ... specifying the appropriate operation options and equivalent configs for both database types:

    //If the operation is a set(), and the referenced structures 
    //don't exist, they will be created automatically.
    
    var webSQLOptionsObj = {
        databaseName: "Example_DB",
        databaseDisplayName: "Example DB",
        databaseVersion: "",
        estimatedDatabaseSize: 1024 * 1024,
        tableData: {
            name: "Main",
            keyColumnName: "lastName",
            columnDefinitions: "(lastName TEXT PRIMARY KEY, firstName TEXT)"
        }, 
        tableIndexDataArray: [name: "First_Name_Index", columnNames: "(firstName)"]
    };
    
    var indexedDBOptionsObj = {
        databaseName: "Example_DB",
        databaseVersion: 1,
        objectStoreData: {
            name: "Main",
            keyPath: lastName,
            autoIncrement: false
        },
        objectStoreIndexDataArray: [
            {name: "First_Name_Index", keyPath: "firstName", unique: false, multiEntry: false}
        ],
    };
    
    var optionsObj = {
        conductDisjointly: false, 
        webSQL: webSQLOptionsObj, 
        indexedDB: indexedDBOptionsObj
    };
    

    ... and conducting the operation:

    bakedGoods.set({
        data: [
            {value: {lastName: "Obama", firstName: "Barack"}}, 
            {value: {lastName: "Biden", firstName: "Joe"}}
        ],
        storageTypes: ["indexedDB", "webSQL"],
        options: optionsObj,
        complete: function(byStorageTypeStoredItemRangeDataObj, byStorageTypeErrorObj){}
    });
    

    Its simple interface and unmatched storage facility support comes at the cost of lack of support for some storage facility-specific configurations. For instance, it does not support the conduction of storage operations in WebSQL tables with multi-column primary keys.

    So if you make heavy use of those types of features, you may want to look elsewhere.

    Oh, and for the sake of complete transparency, BakedGoods is maintained by this guy right here :) .

    0 讨论(0)
提交回复
热议问题