This is an impressive proof of concept, but the single most powerful thing about key value stores / document-based DB's is their independence from SQL.

Lately I have been experimenting with MongoDB and, personally, the divergence from SQL is refreshing and helps me rethink those engrained RDBMS principles!

Perhaps this could be useful when migrating from a legacy SQL system?

> The single most powerful thing about key value stores / document-based DB's is their independence from SQL.

The most powerful thing about key/value stores is the scalability and other features; it's a significant loss that it doesn't have a powerful ad-hoc query language. Adding SQL doesn't hurt it's "independence" from SQL as it is merely an add on.

From a technical point of view, I agree that scalability is a killer feature. But from the point of someone learning about key/value stores, taking a entirely different approach is helpful. For me, it has been invaluable to detach my thought process from any concept of SQL and think different.

If education and mind expansion were the point of distributed key/value stores, then this would be a valid argument. For some people, I suppose it is. But, for most folks they are a means to an end...and the end is not making people more clever. The end is building scalable applications for most folks, and an SQL query layer doesn't impede that.

SQL is a query language and, frankly, doesn't need to be tied to an RDBMS. Look at SimpleDB and now CouchDB.

However, with new k/v stores and other database models, I don't see why we need to mangle SQL to work with every single type of data model. If it can be mapped, great. Otherwise, let each database build a query language to truly exploit its power.

SQL is the rosetta stone between many data storage engines. If NoSQL is going to succeed, I would argue that they will need to standardize their query languages.

There countless paradigms that prove my point. The web won out over the desktop. Relational won out over flat files. XML over other formats.

If the paradigm of NoSQL will succeed, customers will want some belief that they can ultimately escape the clutches of a particular vendor's product.

Note, however, that the SimpleDB 'select' syntax is SQL-like and not actually SQL.

The danger here is a proliferation of syntactically similar but semantically different query languages, and mass confusion as developers attempt to switch between data storage providers.

How about using a real SQL engine, then? http://www.sqlite.org/vtab.html among other possibilities.

I don't see independence from SQL as a win. Rather than submitting a query in a declarative language and letting the database run a query planner, you are acting as a human query planner, generating row access strategies, and pasting that generated code directly into your higher-level source.

Isn't this an SQL view/ presentation on couchdb? Are there any disadvantages for using it this way?

It uses temporary views. Very slow. Damien Katz has a comment on the original post saying how it might be done efficiently.

I hope they speed up temporary views in the future. MongoDB has a nice query-style language, and I think that it really helps ease some concerns for noobs to document-style data, plus, adds a nice level of flexibility.

It's relatively easy to make a SQL front-end for any single-node database.

For distributed databases it is harder.