Conversion from WebSQL to IndexedDB

Question

I am currently working on a mobile application for time card submission that works with an already existing accounting application. Needless to say, this application relies heavily on relational databases and that particular reliance translates to the mobile app.

In it's current state, the mobile application uses WebSQL for offline access of tables that are loaded onto the device while the user has internet access. Time Cards are created on the local database and then later uploaded when the user regains internet access. This functionality is the core of the application.

My question is whether a transition to IndexedDB is A.) Feasible and B.) A smart move. Had WebSQL avoided deprecation, this wouldn't be an issue. I am beginning to understand IndexedDB better and how JSON can make it useful for relatively complex data storage, but I can't really wrap my head around whether it can actually replicate the functionality of a relational database.

Based off the requirements of the application, it appears that IndexedDB is not an alternative, but I'm still very new to the concept and open to enlightenment.

So can IndexedDB potentially be an alternative? Can IndexedDB be used to replicate the functionality of a database with multiple related tables with large amounts of data. If so, where can I find information on how to do it. If not, do I have an alternative to the two? (Assuming WebSQL does, in fact, lose support and IndexedDB isn't viable).

On a related note, would IndexedDB speed up the population of the local database? PHP is currently used to populate the database while the user is online and it does take a decent amount of time to fill of table with a hundred or so options. When it gets near a thousand, the application just flat out breaks down (This is an uncommon occurance and the clients are strongly discouraged from using that much data).

Any help on this would be great, I'm very new to programming in general and VERY new to web development.

Answer 1

According to http://www.caniuse.com/indexeddb , the support for indexedDB is rather limited, so I wouldn't jump to it for now. But that will most likely change in the future, when the implementations mature.

Personally, IndexedDB looks strange and complicated, especially when you go beyond simple single-table operations. I have not run any actual tests on it, but since you have to do some things (like join records) manually, you will end up with quite a lot more JS code, which translates to more area for bugs to hide.

So can IndexedDB potentially be an alternative? Can IndexedDB be used to replicate the functionality of a database with multiple related tables with large amounts of data. If so, where can I find information on how to do it. If not, do I have an alternative to the two? (Assuming WebSQL does, in fact, lose support and IndexedDB isn't viable).

A quick search brings up http://blog.oharagroup.net/post/16394604653/a-performance-comparison-websql-vs-indexeddb , which shows some patterns for IndexedDB multiple table usage. It also shows some performance comparison, which looks promising for IndexedDB. However, see this answer and take this benchmark with a grain of salt.

On a related note, would IndexedDB speed up the population of the local database? PHP is currently used to populate the database while the user is online and it does take a decent amount of time to fill of table with a hundred or so options. When it gets near a thousand, the application just flat out breaks down (This is an uncommon occurance and the clients are strongly discouraged from using that much data).

I am a developer of a similar app for a different industry, and my experience is quite different: even on an older iPhone 3GS, the WebSQL solution runs adequately - we have tested schemas with several thousand records per table with no significant slowdowns. Are you maybe inserting each row in a separate transaction?

Most of our clients are satisfied with the app since it runs on iPads, iPhones, Android tablets and Google Chrome. But one client's security requirements only permit usage of Windows and IE, no alternative browsers or non-Windows mobile devices. That is the only scenario we've seen where WebSQL doesn't cut it. We looked into IndexedDB and native apps, and so far we consider native apps a better option (C# base library could be shared between Xamarin and Windows Phone apps, not to mention C# would be so much more pleasant to code than loose-typed JS callback hell).

Answer 2

I'm a couple of years late, but figured I'd drop in and answer the questions of OP (for both his benefit (possibly) and that of anyone who finds themselves here with the same questions) which were not directly answered already, as well as offer some suggestions!

do I have an alternative to the two? (Assuming WebSQL does, in fact, lose support and IndexedDB isn't viable).

IndexedDB is the only database that remains on the W3C standards track at this point, and as such, is pretty much the only option as far as native client-side databases go.

So can IndexedDB potentially be an alternative? Can IndexedDB be used to replicate the functionality of a database with multiple related tables with large amounts of data.

Well...

IndexedDB is a non-relational document store.

• Non-relational: Does not allow for the definition of any relationships between the entries which exist in its object stores (tables). All such relationships must be defined and maintained by the application.

• Document store: A repository of documents, which are arbitrarily structured data items.

A relational database, on the other hand, supports both the definition and maintenance of relationships between table entries. The majority of these databases are also row stores, which (as you probably know) are repositories of tuples contained in tables which define their respective structures.

So to answer your question, yes, you can replicate in IndexedDB the functionality provided to you by your relational database. And if any of the data items in the store are related to each other in any way, you'll have to, to some extent.

But considering the client-side database is simply a temporary stop-over for your data, it'd be wise to replicate only the bare minimum to maintain the integrity of your data on there, and just take advantage of the rest of such functionality as it exists in the relational database on the server side once the data is transferred.

If the thought of converting still seems palatable, go for it!

But before you do, there are a couple of things you should know about IndexedDB. The first should be evident given the type of database that it is: it does not natively support SQL. The second is that its API is... unwieldy to say the least.

Given these things, I suggest you check out BakedGoods. With it, placing one or more data items in an IndexedDB database, for example, is as simple as:

bakedGoods.set({
    data: [{key: "key1", value: "value1"}, {key: "key2", value: "value2"}],
    storageTypes: ["indexedDB"],
    function(byStorageTypeStoredItemRangeDataObj, byStorageTypeErrorObj){}
});

Since the replication of some relational database functionality may require complex CRUD operations, you may want to take advantage of BakedGood's support for user-defined storage operation functions.

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

Answer 3

Generally developers who are working with SQL have difficulty in using indexeddb due to its complex apis.

The solution is to use any indexedb library which makes indexedb super easy, but again in order to use the library i need to know few concept of indexeddb.

JsStore is an indexeddb library which removes indexeddb complexity and makes the use of indexeddb super easy. It provides Sql like apis which makes it easy to learn.

Lets say - you have sql query : select * from table_name where id=1 and name='abc'

In JsStore - the query will be :

var con = new JsStore.Instance(db_name);
con.select({
     From:table_name,
     Where: {
         Id: 1,
         Name:'abc'
     }
}).then(function(result){
   console.log(result)
})