4 ms·

Bah. People keep confusing the syntax with the data model. SQL is simply a notation to express theorems in relational set theory. It's pretty much the only pure

by aristus 10y ago

Bah. People keep confusing the syntax with the data model. SQL is simply a notation to express theorems in relational set theory. It's pretty much the only pure-functional, side-effect-free programming language that's actually gone mainstream [0]. If you look carefully at the APIs of the "No SQL" databases, you'll find them introducing relational set theoretic features. To paraphrase Paul Graham's unbearably smug comment about Lisp: once you add filter, group by, and join, you can no longer claim to have invented a new query language, just another dialect of SQL. Math has this funny habit of remaining true no matter how many mean things people say about it on their blogs. [0] I mean basic core SQL, not the vendor-specific stuff like PL/SQL.

lanna 10y ago
> side-effect-free How is SQL side-effect-free if it has INSERT, UPDATE, DELETE?
- wvenable 10y ago
  Those aren't side-effects, they are the main effects.
mindcrime 10y ago
Along those same lines, you can - in principle - have a relational database that doesn't use SQL (although there aren't many in practice), and plenty of "NoSQL" databases use SQL (or a VERY SQL-like language). You can layer SQL on top of a lot of different data models, although the mapping will be cleaner in some cases than others.
- aristus 10y ago
  Absolutely. But at that point we are quibbling over syntax instead of semantics, which is not that interesting. In practice you can do hierarchical models in SQL just fine (cf Oracle's ANCESTOR features, or AsterData's regexps), and bag-of-features stuff using JSON. Graph models are more awkward, but graph models are always awkward.
gshulegaard 10y ago
This is interesting, but I admit I am a bit confused. Having read "An Introduction to Database Systems" by C.J. Date (http://www.amazon.com/Introduction-Database-Systems-8th/dp/0321197844 http://www.amazon.com/Introduction-Database-Systems-8th/dp/0...), I have a tremendous appreciation for Relational Algebra and Theory which allows for the closed functional nature/syntax of SQL which holds true across the various normal forms (1st-5th). Perhaps due to my own lack of understanding, I always assumed that without an underlaying relational model SQL loses its closure. So for me, I always thought the distinction between SQL and NoSQL was whether or not the underlying database model was relational. Sure for many of the queries against a non-relational model you could adopt a SQL-like syntax (which many languages seek to do), but it would no longer be operating in the closed Relational Algebra space. Could you comment on this and help me understand the finer points/where I went wrong?
- btilly 10y ago
  Syntax and being relational are orthogonal. You can set up non-relational data structures in SQL. You can set up a relational data structure in virtually any programming language. However what the NoSQL people are learning is that smart developers really want relational models. So they are offering the features that can be used to achieve that.
  - gshulegaard 10y ago
    That's where I think where most NoSQL proponents start to miss the value of relational models and the closed Relational Algebra it allows. As I understood it, SQL was a language for describing the Relational Algebra which was a closed mathematical concept. You can take the syntax, assign functions to produce output from a non-relational model, but it's no longer SQL...and it's underlying power (the closed Relational Algebra) is no longer present. So in a sense syntax and being relational are orthogonal, but syntax isn't the defining characteristic of SQL (or why it's so powerful). I think a more insightful statement is: SQL (Relational Algebra) and being relational are codependent and relational and non-relational are orthogonal. Which, if I am not mistaken (and again I am still trying to understand the finer points which is what motivated my original comment), NoSQL people fundamentally _cannot_ offer a query language similar to SQL based on the closed relational algebra. They can mimic the syntax to make it more intuitive for new users coming from traditional RDMBS environments, but it's fundamentally _not_ SQL/relational algebra. But again, I am just a cursory admirer/learner and I am still trying to iron out my own understanding of the underlying theory. So all additional information/clarifications welcome :)
jimbokun 10y ago
NoSQL DBs became popular because performant distributed joins are hard. Joins (and aggregate, group by, etc.) were thrown out to make horizontal scale out simpler. Cassandra CQL, for example, shares keywords with SQL, but the key-value(ish) data model couldn't be more different, and is much easier to scale horizontally. Various systems are trying to solve the distributed join problem while keeping easy horizontal scaling, and if they succeed the NoSQL label won't make sense for those systems any more.
- aristus 10y ago
  Yep. I spent 2.5 years at MemSQL, which nailed its colors to the mast of solving distributed joins via good old SQL. It is absolutely possible to have fast scaled distributed SQL, and a pony. The caveats are falling away one by one.

by aristus 10y ago

lanna 10y ago

> side-effect-free How is SQL side-effect-free if it has INSERT, UPDATE, DELETE?

wvenable 10y ago
Those aren't side-effects, they are the main effects.

mindcrime 10y ago

Along those same lines, you can - in principle - have a relational database that doesn't use SQL (although there aren't many in practice), and plenty of "NoSQL" databases use SQL (or a VERY SQL-like language). You can layer SQL on top of a lot of different data models, although the mapping will be cleaner in some cases than others.

aristus 10y ago
Absolutely. But at that point we are quibbling over syntax instead of semantics, which is not that interesting. In practice you can do hierarchical models in SQL just fine (cf Oracle's ANCESTOR features, or AsterData's regexps), and bag-of-features stuff using JSON. Graph models are more awkward, but graph models are always awkward.

gshulegaard 10y ago

This is interesting, but I admit I am a bit confused. Having read "An Introduction to Database Systems" by C.J. Date (http://www.amazon.com/Introduction-Database-Systems-8th/dp/0321197844 http://www.amazon.com/Introduction-Database-Systems-8th/dp/0...), I have a tremendous appreciation for Relational Algebra and Theory which allows for the closed functional nature/syntax of SQL which holds true across the various normal forms (1st-5th). Perhaps due to my own lack of understanding, I always assumed that without an underlaying relational model SQL loses its closure. So for me, I always thought the distinction between SQL and NoSQL was whether or not the underlying database model was relational. Sure for many of the queries against a non-relational model you could adopt a SQL-like syntax (which many languages seek to do), but it would no longer be operating in the closed Relational Algebra space. Could you comment on this and help me understand the finer points/where I went wrong?

btilly 10y ago
Syntax and being relational are orthogonal. You can set up non-relational data structures in SQL. You can set up a relational data structure in virtually any programming language. However what the NoSQL people are learning is that smart developers really want relational models. So they are offering the features that can be used to achieve that.
- gshulegaard 10y ago
  That's where I think where most NoSQL proponents start to miss the value of relational models and the closed Relational Algebra it allows. As I understood it, SQL was a language for describing the Relational Algebra which was a closed mathematical concept. You can take the syntax, assign functions to produce output from a non-relational model, but it's no longer SQL...and it's underlying power (the closed Relational Algebra) is no longer present. So in a sense syntax and being relational are orthogonal, but syntax isn't the defining characteristic of SQL (or why it's so powerful). I think a more insightful statement is: SQL (Relational Algebra) and being relational are codependent and relational and non-relational are orthogonal. Which, if I am not mistaken (and again I am still trying to understand the finer points which is what motivated my original comment), NoSQL people fundamentally _cannot_ offer a query language similar to SQL based on the closed relational algebra. They can mimic the syntax to make it more intuitive for new users coming from traditional RDMBS environments, but it's fundamentally _not_ SQL/relational algebra. But again, I am just a cursory admirer/learner and I am still trying to iron out my own understanding of the underlying theory. So all additional information/clarifications welcome :)

jimbokun 10y ago

NoSQL DBs became popular because performant distributed joins are hard. Joins (and aggregate, group by, etc.) were thrown out to make horizontal scale out simpler. Cassandra CQL, for example, shares keywords with SQL, but the key-value(ish) data model couldn't be more different, and is much easier to scale horizontally. Various systems are trying to solve the distributed join problem while keeping easy horizontal scaling, and if they succeed the NoSQL label won't make sense for those systems any more.

aristus 10y ago
Yep. I spent 2.5 years at MemSQL, which nailed its colors to the mast of solving distributed joins via good old SQL. It is absolutely possible to have fast scaled distributed SQL, and a pony. The caveats are falling away one by one.