
Beyond HTML5: Database APIs and the Road to IndexedDB - barredo
http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/
======
vessenes
Mostly, I like new technology. In fact, I had to hand re-compile CouchDB today
for a production server, and I didn't complain at all. Really.

But, this seems silly. Why are the developers creating their own new way of
storing and retrieving large, structured datasets? Don't we already have a
reasonably good way of doing that? One that's taught around the world?

Complaining, as they do in their doc, that SQLite doesn't implement all of
SQL92 is totally silly. I think they'd be better off implementing a custom
JSON <-> SQL binding CRUD package than creating a totally new object-
interactive layer on top of SQLite. (Yes, from the article, they use SQLite as
the underlying engine.)

To me, the arguments for this just don't make sense.

Also, priceless quote from the article: "IndexedDB does not currently have an
API specified for doing a join between different object stores. As a result,
the example opens a cursor to the kids object store and an object cursor on
the kidId index on the candySales object store and performs the join
manually."

I know I'm sniping. But, for this, we are supposed to be happy to give up SQL?

~~~
seldo
Really, this is just "NoSQL for the web". And I have the same problem with it
that I have with all NoSQL APIs, which is that it's not noticeably simpler or
more performant, it just looks a bit more "object-y". As you note, it doesn't
even have a way of doing joins. (There's no reason you couldn't support SQL in
the browser that allowed you to create tables with indexes)

The reason the SQL standard exists is not because it's the absolute best way
of accessing structured data, but because a _standard_ way of accessing
structured data is useful in and of itself. It has economies of training and
learning and allows for some limited amount of portability between DB engines.

In 5 years, somebody is going to invent some kind of meta-API that allows you
to use a single common API to access all of cassandra, couchdb, mongodb, and
the rest, and I'm just going to laugh and laugh.

~~~
mjw
And while SQL is not the absolute best way of accessing structured data, the
theory which it's almost-but-not-quite based on, the relational model, DOES
have demonstrable and very well-researched advantages over hierarchical
database models when it comes to working with structured data at a high level.

------
eob
Why can't we just have SQL92 on the client side along with some nice API that
accepts keyed JSON objects and performs the standard CRUD operations with
them.

I get that people want simple Key-Value and Object storage APIs because they
provide nice abstractions for a particular set of use-cases, but that doesn't
warrant throwing out relational databases & SQL.

The correct fix for this is to require full SQL92 compliance in the HTML spec,
patch up SQLite to plug its areas of noncompliance, and then let framework
designers address data access APIs (that all persist to relational data) at
the JavaScript leve.

~~~
mjw
Indeed.

It's absolutely trivial to write an reasonably-performing key-value store on
top of even the most minimal subset of SQL.

The reverse is most certainly not true.

------
swannodette
Sigh. Looking at this and the walk-through you would think Mozilla would have
a little more vision. SQL queries on the client? Guess I was secretly hoping
Mozilla would adopt something more along the lines of CouchDB.

~~~
FooBarWidget
What? Mozilla is explicitly _not_ implementing SQL on the client. Instead
they're implementing some kind of indexed object database.

~~~
swannodette
Wow. Sorry serious case of not reading the code closely enough because of
work. You're totally right. In fact they mention how easy it would be to write
a CouchDB layer on top! Sheesh.

