Re: Replacing WebSQL with a Relational Data Model.

Jonas Sicking wrote:
> On Mon, Oct 25, 2010 at 10:24 AM, Keean Schupke <keean@fry-it.com> wrote:
>> We (www.fry-it.com) produce websites and mobile apps. We have been looking
>> at HTML5 for developing mobile apps, and for the kind of apps that we want
>> to produce the client side WebSQL API provided what we needed. The IndexedDB
>> is not suitable (no joins, no compound indexes etc...).
> [snip]
> One thing that I'm wary of is going the full relational route of
> requiring that values be split up into columns. It's really nice that
> javascript objects can be stored as-is, and then use key-paths to
> access specific values within an object. But I think that should be
> doable while still keeping the benefits of your proposal.

Likewise, personally all data I use is either in graph or k/v format, 
and have found (like many others), that primary speed gains come from 
changing the underlying data model rather than trying to map forwards 
and backwards between objects, graphs and tabular data in a relational 
data model, via SQL.

However, over and above any issues of speed or this-vs-that, I strongly 
feel that universality should be priority number one, what all of us 
*need* is a /single/ standardized storage interface implemented 
everywhere javascript is, and certainly in all the major browsers.

Keean, I think what you are proposing is great, but should be an API 
layered on top of IndexedDB, and which uses IndexedDB - the fact is 
we're dealing with javascript here, focus has to be on handling the 
structures provided (object/array) and getting them in and out of a 
persistence layer as optimally as possible.

Thus, once we have this single universal persistence interface we can 
wrap it up in other model or context specific APIs (such as the one you 
describe), lessons can be learned, bugs filed, and over time speed 
increases and optimizations will be introduced.

The critical point here is that we need only one standardized interface, 
not a perfectly optimized for data-model-x one, not a uses 
query-language-foo one, just something that we can all use to persist 
data from javascript, and wrap in other APIs, that way any optimizations 
made will benefit everybody - regardless of their preferred interface, 
data model & query style.

Best,

Nathan

Received on Tuesday, 26 October 2010 18:04:19 UTC