4 ms·

I am presently researching these so-called NoSQL databases and one thing that I keep wondering is why can't all of these database still support a limited form o

I am presently researching these so-called NoSQL databases and one thing that I keep wondering is why can't all of these database still support a limited form of SQL-like language? Almost any json document could be represented as a db table as far as I can see. Why can't I query using a common language instead of learning each of these NoSQL database's own way of doing simple stuff like returning documents of User object that have a gender field value as 'male'. In SQL, it would be something like "select * from users where gender='male". Why can't NoSQL databases support a query similar to that? Why do they require me to describe a similar request in their own unique syntax? I sometimes get the feeling that coining a term like NoSQL is a marketing gimmick which hurts people actually trying to learn the nuanced differences but I am only getting started. Why can't we extend SQL to support "NoSQL"-specific cases instead of replacing it with nothing. I get that a big part of SQL is joins and the philosophy of joins goes against the idea of NoSQL. The solution to that is to still accept SQL but just throw an exception when join is used with a link to educate the person on alternative implementations.

almost 14y ago
I believe some do offer SQL-like query languages. But if all you support is lookup by key, or even just lookup by field, then SQL really isn't that useful in my opinion. And if your lookups are based on map-reduces that have to be pre-specified then I can't see any place for an SQL-like language at all. SQL is ok for specify queries to relational databases, but I don't think it generalises to any type of store apart from maybe the very basics. And at that point what benefit are you getting appart from a slight, and misleading, sense of familiarity?
- 3amOpsGuy 14y ago
  Yeah Cassandra has CQL and it works pretty well, it's comfortable to use where the cassandra-cli is quite painful for anything other than the very beginning of a project. I believe in earlier releases CQL was slower but now it seems fine. Also the most popular Cassandra client, hector, supports CQL, adopting CQL should be possible for a lot of Cassandra use cases.
4ad 14y ago
Disclaimer: I'm not a DB person, so take everything I say with a grain of salt. I only used a few SQL and NoSQL products and have done it from statically compiled languages. The immediate benefit I perceived when using language constructs instead of SQL was type safety and compile time validation of the query. I hate the chained function calls, I find SQL easier to read, but I would not trade the type safety for a more pleasant syntax.
vampirechicken 14y ago
Joins are in SQL because SQL was developed to query relational databases, and the join is the fundamental assumption of the relational database. I always find it sad that the new data storage engines define themselves under a banner that says "We don't care that everybody who learned how to query a database since 1988 needs to learn a new way because our way is better." Which wouldn't be so bad if it was uniform across engines, but it isn't. It's a new API for each engine. That's a lot of yaks to shave when you already know SQL.
erichocean 14y ago
> In SQL, it would be something like "select * from users where gender='male". Why can't NoSQL databases support a query similar to that? They can and they do, e.g. Cassandra and CQL, which syntactically is the SQL you requested.

almost 14y ago

I believe some do offer SQL-like query languages. But if all you support is lookup by key, or even just lookup by field, then SQL really isn't that useful in my opinion. And if your lookups are based on map-reduces that have to be pre-specified then I can't see any place for an SQL-like language at all. SQL is ok for specify queries to relational databases, but I don't think it generalises to any type of store apart from maybe the very basics. And at that point what benefit are you getting appart from a slight, and misleading, sense of familiarity?

3amOpsGuy 14y ago
Yeah Cassandra has CQL and it works pretty well, it's comfortable to use where the cassandra-cli is quite painful for anything other than the very beginning of a project. I believe in earlier releases CQL was slower but now it seems fine. Also the most popular Cassandra client, hector, supports CQL, adopting CQL should be possible for a lot of Cassandra use cases.

4ad 14y ago

Disclaimer: I'm not a DB person, so take everything I say with a grain of salt. I only used a few SQL and NoSQL products and have done it from statically compiled languages. The immediate benefit I perceived when using language constructs instead of SQL was type safety and compile time validation of the query. I hate the chained function calls, I find SQL easier to read, but I would not trade the type safety for a more pleasant syntax.

vampirechicken 14y ago

Joins are in SQL because SQL was developed to query relational databases, and the join is the fundamental assumption of the relational database. I always find it sad that the new data storage engines define themselves under a banner that says "We don't care that everybody who learned how to query a database since 1988 needs to learn a new way because our way is better." Which wouldn't be so bad if it was uniform across engines, but it isn't. It's a new API for each engine. That's a lot of yaks to shave when you already know SQL.

erichocean 14y ago

> In SQL, it would be something like "select * from users where gender='male". Why can't NoSQL databases support a query similar to that? They can and they do, e.g. Cassandra and CQL, which syntactically is the SQL you requested.