Re: Replacing WebSQL with a Relational Data Model.

Hi,


> 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.
>
>

If we see HTML5 as a replacement for native mobile apps, and desktop apps,
then we have to look at what applications require in terms of data storage
not websites. SQL is very widely used, and that must tell us something.
Nearly all our apps use it.

Lets think about what is currently done on the server. Lots of server apps
use a relational database. With HTML5 we would like to move as much of that
work as possible to the client - so that it uses the client's CPU not the
servers CPU. The HTML5 app will keep a local cache of some of the server
database for offline use. For example a calendar app that keeps the next
months appointments in the client, and allows new meetings to be created
offline. There may be many ways you wish to seach and cross reference the
information, for example you may have a contacts table and an appointments
table. You may use a join to allow the contacts phone number to be displayed
in each appointment. Searching, sorting, grouping, all things you will want
to do.



> 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.
>

I am going to attempt a basic implementation on top of IndexedDB, and also
on top of WebSQL.


>
> 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.
>

The problem is the proposed data model is a subset of the functionality
required. The relational model is a complete algebra (hence the term
relationally complete). With a non-relationally complete storage API there
will always be limitations to what it can do.

Take Firefox for example, it implements IndexedDB using SQLite apparently.
So implementing a relational API if we have to talk to IndexedDB that means
we have to convert from the relational data model to an object model and
then back to a relational model for SQLite. So what I would like to do is
punch through that excess layer in the middle and have the relational API
talk directly to SQLite in the browser implementation. How could you argue
that having an unnecessary middle layer is a good thing?

Of course I am not suggesting that this is more important than getting
IndexedDB working (for me a good relational API is more important, but I can
understand that for a lot of people IndexedDB is all they need).

What I would like to see is the relational API standardised (maybe in the
next version of IndexedDB, maybe as a separate standard), so there is a
relationally complete API available, that browser implementers can implement
using a relational storage engine like SQLite directly, or can be emulated
by an implementation on top of IndexedDB where necessary.


Cheers,
Keean.