[whatwg] Why SQL? was: Comments on updated SQL API

Maciej Stachowiak wrote:
>
> Web App developers are used to using SQL to access storage on the 
> server. Web apps that add offline support are likely to want to store 
> data on the client with a similar structure to data on the server. If 
> some form of object persistence is desired, it could be implemented on 
> top of SQL, and perhaps once it is proven as a storage model some 
> built-in approach could be standardized.
>
1) Far not all web services have relational DB on the back end.
Google and Yahoo web services as an example. 

2) For the cases when there is a SQL DB  data  are
delivered  to the client in  form of JSON or XML that needs
to be deserialised back to flat representation.

It is pretty natural to store/manipulate data "as is".
JS already provide enough constructions to do this:
maps (hash tables) and  vectors(arrays) .

If someone needs things like select() to query complex
data structures then it is a matter of JS itself.
See http://code.google.com/p/trimpath/wiki/TrimQuery
as an example. Things like TrimQuery backed by simple
Object.persist() will do the job *when it is really needed*.

>> I suspect that initial simple *Berkeley DB*
>> alike proposal is what really needed and enough in
>> most cases.
>
> Berkeley DB is just an on-disk hashtable. Such simple key/value story 
> with no support for complex queries can already be found in the 
> Storage API. 
> <http://www.whatwg.org/specs/web-apps/current-work/#the-storage>. 
> Low-structure storage can indeed be good for simple cases.
>
> (Actually, the Berkeley DB API has a lot more to it than that, but 
> exposing something resembling the full API would require a large 
> amount of API surface area.)
>
If it is storage API already why do we need SQL then?
I think either storage API or SQL API shall be eliminated.
Having them both ...

I am not against new things really. It just appears as
UA will look like Christmas tree one day.
Each member of the family is adding their own stuff.
And someone put there SQL engine because it happens to lie on the shelf
nearby and granddad decide that his old canvas will also look cool
there and so on.  For Christmas tree such decoration approach would work
but for serious system design ...

Client storage shall be as simple and universal as possible to be short.

Andrew Fedoniouk.
http://terrainformatica.com

Received on Tuesday, 25 September 2007 17:56:03 UTC