Web SQL & Datatables

Web SQL & Datatables

danw82danw82 Posts: 6Questions: 0Answers: 0
edited February 2011 in General
Hi All,
Has anyone ever tried Web SQL with datatables? I know it’s not that widely supported yet but I imagine it soon will be and as I am about to do some ajax calls to pipeline data I started wondering about storing table data in a web SQL database. The data would basically just be historical tables so the rows will rarely change so it makes sense to store them on the client side, yet there will be overhead in checking that the rows haven’t changed and updating them if they have.

5 Minutes ago I was thinking wow, datatables with Web SQL but now I'm thinking would there really be much to gain by the time the serverside and client side databases have been synced?

Personally I'm starting to think that it would only be useful to store 'joined table' information this way.
For example lots of tables I use have joins to other much smaller tables that are used throughout the entire system and across multiple reports. So when downloading the information for datatables be it on page load or from an Ajax call rather than get the full string we could just download the id and then replace this at the client side e.g. 1=Ford, 2=Audi etc

What’s people general opinion of this? Would it have any real payback? Is it worth the effort? It would speed up pipelining and page loads depending upon the overhead of maintaining the linked tables, and has anyone tried anything like this?

Replies

  • allanallan Posts: 63,180Questions: 1Answers: 10,411 Site admin
    Hi danw82,

    I haven't heard of anyone using Web SQL with DataTables yet, but I'm sure that it can readily be done. I know that integration has been done against the SQL DB in AIR and in Gears - so Web SQL should be similar. If you want to use a reasonably large number of rows - say 1000-10000 - and not put too much load on your server, then it probably is quite a good idea to implement. You can just preload the data into the local SQL DB and let it go. Much more data than that, and the initial load might be a little too much for the initial loading time - less data and the client-side storage can handle it no problem. The real saving is from dropping out the need to set up the HTTP request every time you want more data (although pipelining can be used to mitigate that already).

    So yes, I'd say there is certainly a place where it is useful and if your application falls into that range, then it might well be worth the effort, but it would need to be considered if the trade-offs are worth it (including the development time).

    One other consideration is that it appears the Web SQL spec is no longer being pursued by the W3C. I don't know what this means for the Webkit and Opera support of the spec - they might wish to maintain it themselves or not. Again it's another trade-off to consider :-)

    Regards,
    Allan
  • danw82danw82 Posts: 6Questions: 0Answers: 0
    Hi Allan,
    Thanks for your input but if its no longer being pursued by W3C then theire not much point in me investing more time into this.

    Might be worth downloading a supporting javascript array containing all distinct values for a column and long with and ID and then replacing the ID for each row with the value. Downside is the download would be done on each page load but on the plus side it would have some pay back for large tables.
    I think though for now at least I'll just stick with pipelining the data.

    Best Regards
    Dan
This discussion has been closed.