Hacker News new | comments | show | ask | jobs | submit login
Beyond HTML5: Database APIs and the Road to IndexedDB (hacks.mozilla.org)
34 points by barredo on June 1, 2010 | hide | past | web | favorite | 12 comments

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?

Yep I too was quite disappointed by this.

The article contained a lot of bombast about giving up on SQL and taking the opportunity to do some blue-sky thinking about creating a better API for 'structured data'.

I was hoping this meant they were going to replace SQL with a more modern relational API, correct some of the flaws in SQL while they're at it and base it truly on the relational algebra.

Turns out it's just yet another souped-up key-value store, or 'hierarchical database'. No joins, no real relational functionality to speak of. I thought we already had a client-side key-value store API?

If only people would actually read some of the theory on relational databases before eagerly reinventing a square wheel.

</old fart before his time>

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.

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.

Yes, IndexedDB is a lower-level API. As the article says, we think it's both practical and desirable to implement SQL on top of IndexedDB. I think this is a harder but better path to a true interoperable standard, for the reasons I outlined here: http://news.ycombinator.com/item?id=1396453

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.


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.

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.

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

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.

They show two different client side storage mechanisms. WebDB and IndexedDB. The web one is SQLite, it exists right now on most of the modern browsers. IndexedDB is what they're planning on implementing, if you read the article, it's essentially the basis for something like CouchDB.

Well, WebDB is not exposed to the web as a whole, only extensions and 'trusted code'.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact