3 ms·

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 s

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 16y ago
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 16y ago
  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.
mjw 16y ago
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>
mbrubeck 16y ago
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 http://news.ycombinator.com/item?id=1396453

seldo 16y ago

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 16y ago
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.

mjw 16y ago

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>

mbrubeck 16y ago

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 http://news.ycombinator.com/item?id=1396453