Re: Replacing WebSQL with a Relational Data Model.

Just some thoughts that occurred to me this morning:

I guess the issue of exactly how you cache data on the client side varies
> based on the application, however in all but a few cases it appears to me
> that the optimal solution is to store the data in a structure/format which
> the application actually uses. A common example may be storing a User Object
> (complete with nested objects) rather than a several tables each with a
> component part in it.
>

This is interesting. When dealing with data I find it easier for the
application to work with the data in a relational format. With a
relationally complete language everything you can do in your normal
programming language you can do in the relational language (except doing
things like the transitive closure). The relational language has the
advantage that you can do all this without needing loops. From a computer
language point of view asking two join two relations is higher level than
looping through and looking up links (because you are specifying what you
want not how to do it). This is like the difference between programming an
imperative language an Prolog.

Once you have learned a relational language like SQL and internalised it, it
is much easier to manipulate the data by specifying the what, and not having
to bother about the how. So with SQL you try an do all the processing in
SQL.

If you wanted to do graph constraint solving, you would implement the graph
as a table and implement the constraint solver pass in SQL.

Obviously this can be slower than doing it in memory with objects. The
critical point is when you have more data than will fit in memory. So if you
have lots of data - too much to read it all into memory at once, then the
best way to deal with it is to port your algoritm to SQL and use a
relational data base. If it will all fit in memory then I would take the
objects approach, and some kind of object store would be great.

This is a very good example! You may well be interested in having a quick
> look at the "Motivating Writing" section of [6] which outlines just such an
> application, and that document together with [7] covers a slightly different
> approach to getting that contacts phone number displayed alongside each
> appointment, using Links rather than Joins.


Is this fast enough? Power users have 5000 contacts, Just getting HTML5 to
produce a scrolling list that long that is fast enough to fling properly on
a mobile device is a struggle.

So, my point was that although IndexedDB is neither optimal for your
> preferred data model or mine, it does cater for us both, and everybody else,
> allowing us to get on and do our jobs, implement APIs, and build HTML5
> client side web applications.
>
>
This is where we differ, as I think it may allow it, it will not make it
practical (from the programmers point of view) nor usable (from the end user
tying to use the app).

Remember we have to perform reasonably against native iPhone / Android apps
or people will not use HTML5 apps.


Cheers,
Keean.