11 ms·

> All these database aspects remained virtually unchanged since 1970, which is absolutely remarkable. Thanks to the NoSQL movement, we know it's not because of

> All these database aspects remained virtually unchanged since 1970, which is absolutely remarkable. Thanks to the NoSQL movement, we know it's not because of a lack of trying. Kind of an aside, but I find it odd that people treat "relational" and "SQL" as synonymous (as well as "non-relational" and "NoSQL"). You could make a relational database that was managed with a language other than SQL, right?

bena 5y ago
As the pirate meme says, "Well yes, but actually no". This is kind of like a sticking effect. It got in at the right time and it was good enough and there wasn't enough interest in developing something to replace it that it just became standard. But if you want to get down to it, any entity data model implemented is kind of an attempt at a replacement.
manbart 5y ago
Tutorial D is one such example of a non-SQL relational db language
datatrashfire 5y ago
You're absolutely correct, but in practice I'm not aware of any relational databases with widespread adoption that don't use SQL.
- bayesian_horse 5y ago
  RethinkDB comes to mind. "Widespread adoption" is a very fungible term.
  - BoiledCabbage 5y ago
    As an FYI, I don't belive that's a correct use of the term "fungible".
    - bayesian_horse 5y ago
      Fungible is very fungible.
    - seanhunter 5y ago
      Indeed. Two things are fungible if one can be replaced by the other.
chana_masala 5y ago
Your intuition is correct. The book "Designing Data Intensive Applications" by Martin Kleppmann goes into detail about this, including some of the history.
roenxi 5y ago
Which in itself is confusing given the upside potential of having relational model without the baggage. Hadley Wickham has had huge success in the context of R re-implementing the relational model without SQL (see: dplyr). It is more user friendly and much more pleasant to use than the mess that database users have to put up with.
- andylynch 5y ago
  dplyr and friends are great! But probably difficult to implement the same idioms in languages less open to features like R’s non-standard evaluation.
mulmen 5y ago
Yes. PostgreSQL is a reference to the Post Ingres database (POSTGRES) adopting SQL. Ingres used QUEL. The POSTGRES database used POSTQUEL which was similar to Ingres’ QUEL. This is why the Postgres C library is called libpq (library post quel) https://en.m.wikipedia.org/wiki/QUEL_query_languages https://en.m.wikipedia.org/wiki/QUEL_query_languages https://en.m.wikipedia.org/wiki/PostgreSQL# https://en.m.wikipedia.org/wiki/PostgreSQL#
- deleted 5y ago
  [deleted]
goto11 5y ago
True, but SQL is (for better or worse) the de-facto standard query language for relational databases. The alternatives are all very niche. I would like a better alternative, but it would need some very significant benefits compared to SQL to gain any traction. SQL is just so entrenched at this point that even NoSql database engines are adding support for pseudo-SQL query languages (which is really the worst of both worlds - the clunkyness of SQL syntax without the power of the relational model).
- kodemager 5y ago
  I’m curious as to why you find sql to be clunky, I find it extremely on point in most cases. I mean, how would you write a SELECT that was better than: SELECT whatever FROM thisplace? I know you can make it clunky with parameters and crazy stored procedures, and I’ve myself been guilty of a few recursive SQL queries that most people who aren’t intimate with SQL struggle to understand quickly, but I consider those things to be bad practice that should only be done when everything else is unavoidable. The fact that SQL is still the preferred standard sort of speaks volumes to me about how good it is. We’re frankly approaching something similar with C styles languages. I recently did a gig as an external examiner, and it took me a while to realise that some code I was reading by a student in their PDF report was Kotlon and not TypeScript, because they look so alike.
  - faho 5y ago
    One very very simple fix is to mention the table first: FROM this SELECT whatever This already allows autocomplete for the attributes to work, and has an easier mental model - you think about the tables, then you think about their attributes. It also matches relational algebra better, where you'd do the projection (picking the attributes you want) at the end. But anyway, simple cases being simple doesn't mean the language isn't horrible for more complex ones. One thing I always complain about is join clauses making it easy to do the wrong thing (NATURAL JOIN) and annoying to do the correct thing (joining on the defined foreign keys).
    - skeeter2020 5y ago
HelloNurse 5y ago
But you could also use SQL for that new RDBMS, or support multiple query languages. It doesn't matter, all relational databases are very similar because they are relational: they do the same things, potentially in the same way, regardless of the query language front end. Apart from being subjectively displeased at SQL syntax, most problems with SQL are actually query language independent issues in the RDBMS: maddening proprietary extensions, implementation limits, nonportable details, library and system issues (e.g. character encoding and default configurations). The best alternative query languages can do is making certain queries (advanced, rare ones) easier to express.
simonh 5y ago
It's for similar reasons that people call vacuum cleaners 'hoovers', they 'google' for things on DuckDuckGo, they 'Xerox' documents on a Cannon copier, all on-road reflective lane markers are a 'Catseye' etc. It may not be accurate but I don't find it at all odd.
uvdn7 5y ago
NoSQL was trying to “break” the relational model. It just happens to have “SQL” in its name. I intentionally avoided associating relational model with SQL in the article. Maybe I failed lol.
samatman 5y ago
Well if NoSQL had called their movement "non-relational databases" that would have been an obviously bad idea, right? But the idea of never writing SQL again remains compelling to a certain sort of mindset, one which I have been known to share when throwing myself against the proverbial wall. SQL isn't a bad dialect with which to hand-roll queries against relational data. I'm quite sure there's room for improvement, especially when it comes to generating queries; I've dipped my toes in this and the compiler has to 'think in SQL' eventually, it's not composable in the way that it should be. But "SQL is annoying and ORMs are terrible" is, from my recollection, the sentiment which gave us the meteoric (pun intended!) rise of Mongo, and "relational modeling isn't negotiable" is the iron fact of our profession which lead to its ignominious fall.
dotancohen 5y ago
> You could make a relational database that was managed with a language other than SQL, right? Other commenters have shown examples of non-SQL relational databases. However, all the alternatives were also examples of Structured Query Languages. Languages designed to query a data store with _Structure_.
mamcx 5y ago
One branch that was super-popular in the day was the dbase family (I work in FoxPro, it was THE dream). Working in Fox dispel many of the weird limitations of sql (and BTW, you can use SQL on Fox alike linq, is first-class). The #1? You can build ALL using the relational model. After MS kill Fox my career can be summarized as: Trying N workarounds because I don't have Fox anymore. Other langs (python, delphi, f#, rust) capture a little of the magic or make the workaround bearable, but none is as productive.
vaughan 5y ago
SQL is simply converted into a logical relation algebra tree. So anything that can do that could be used. It's a shame that PSQL doesn't provide an API for this, then all the quirks of SQL could be fixed. However, then we would probably have a proliferation of non-standard SQL like what happened with JavaScript, and standard tooling couldn't be used. SQL is somewhat nice because its fairly well standardized.

bena 5y ago

As the pirate meme says, "Well yes, but actually no". This is kind of like a sticking effect. It got in at the right time and it was good enough and there wasn't enough interest in developing something to replace it that it just became standard. But if you want to get down to it, any entity data model implemented is kind of an attempt at a replacement.

manbart 5y ago

Tutorial D is one such example of a non-SQL relational db language

datatrashfire 5y ago

You're absolutely correct, but in practice I'm not aware of any relational databases with widespread adoption that don't use SQL.

bayesian_horse 5y ago
RethinkDB comes to mind. "Widespread adoption" is a very fungible term.
- BoiledCabbage 5y ago
  As an FYI, I don't belive that's a correct use of the term "fungible".
  - bayesian_horse 5y ago
    Fungible is very fungible.
  - seanhunter 5y ago
    Indeed. Two things are fungible if one can be replaced by the other.

chana_masala 5y ago

Your intuition is correct. The book "Designing Data Intensive Applications" by Martin Kleppmann goes into detail about this, including some of the history.

roenxi 5y ago

Which in itself is confusing given the upside potential of having relational model without the baggage. Hadley Wickham has had huge success in the context of R re-implementing the relational model without SQL (see: dplyr). It is more user friendly and much more pleasant to use than the mess that database users have to put up with.

andylynch 5y ago
dplyr and friends are great! But probably difficult to implement the same idioms in languages less open to features like R’s non-standard evaluation.

mulmen 5y ago

Yes. PostgreSQL is a reference to the Post Ingres database (POSTGRES) adopting SQL. Ingres used QUEL. The POSTGRES database used POSTQUEL which was similar to Ingres’ QUEL. This is why the Postgres C library is called libpq (library post quel) https://en.m.wikipedia.org/wiki/QUEL_query_languages https://en.m.wikipedia.org/wiki/QUEL_query_languages https://en.m.wikipedia.org/wiki/PostgreSQL# https://en.m.wikipedia.org/wiki/PostgreSQL#

deleted 5y ago
[deleted]

goto11 5y ago

True, but SQL is (for better or worse) the de-facto standard query language for relational databases. The alternatives are all very niche. I would like a better alternative, but it would need some very significant benefits compared to SQL to gain any traction. SQL is just so entrenched at this point that even NoSql database engines are adding support for pseudo-SQL query languages (which is really the worst of both worlds - the clunkyness of SQL syntax without the power of the relational model).

kodemager 5y ago
I’m curious as to why you find sql to be clunky, I find it extremely on point in most cases. I mean, how would you write a SELECT that was better than: SELECT whatever FROM thisplace? I know you can make it clunky with parameters and crazy stored procedures, and I’ve myself been guilty of a few recursive SQL queries that most people who aren’t intimate with SQL struggle to understand quickly, but I consider those things to be bad practice that should only be done when everything else is unavoidable. The fact that SQL is still the preferred standard sort of speaks volumes to me about how good it is. We’re frankly approaching something similar with C styles languages. I recently did a gig as an external examiner, and it took me a while to realise that some code I was reading by a student in their PDF report was Kotlon and not TypeScript, because they look so alike.
- faho 5y ago
  One very very simple fix is to mention the table first: FROM this SELECT whatever This already allows autocomplete for the attributes to work, and has an easier mental model - you think about the tables, then you think about their attributes. It also matches relational algebra better, where you'd do the projection (picking the attributes you want) at the end. But anyway, simple cases being simple doesn't mean the language isn't horrible for more complex ones. One thing I always complain about is join clauses making it easy to do the wrong thing (NATURAL JOIN) and annoying to do the correct thing (joining on the defined foreign keys).
  - skeeter2020 5y ago

HelloNurse 5y ago

But you could also use SQL for that new RDBMS, or support multiple query languages. It doesn't matter, all relational databases are very similar because they are relational: they do the same things, potentially in the same way, regardless of the query language front end. Apart from being subjectively displeased at SQL syntax, most problems with SQL are actually query language independent issues in the RDBMS: maddening proprietary extensions, implementation limits, nonportable details, library and system issues (e.g. character encoding and default configurations). The best alternative query languages can do is making certain queries (advanced, rare ones) easier to express.

simonh 5y ago

It's for similar reasons that people call vacuum cleaners 'hoovers', they 'google' for things on DuckDuckGo, they 'Xerox' documents on a Cannon copier, all on-road reflective lane markers are a 'Catseye' etc. It may not be accurate but I don't find it at all odd.

uvdn7 5y ago

NoSQL was trying to “break” the relational model. It just happens to have “SQL” in its name. I intentionally avoided associating relational model with SQL in the article. Maybe I failed lol.

samatman 5y ago

Well if NoSQL had called their movement "non-relational databases" that would have been an obviously bad idea, right? But the idea of never writing SQL again remains compelling to a certain sort of mindset, one which I have been known to share when throwing myself against the proverbial wall. SQL isn't a bad dialect with which to hand-roll queries against relational data. I'm quite sure there's room for improvement, especially when it comes to generating queries; I've dipped my toes in this and the compiler has to 'think in SQL' eventually, it's not composable in the way that it should be. But "SQL is annoying and ORMs are terrible" is, from my recollection, the sentiment which gave us the meteoric (pun intended!) rise of Mongo, and "relational modeling isn't negotiable" is the iron fact of our profession which lead to its ignominious fall.

dotancohen 5y ago

> You could make a relational database that was managed with a language other than SQL, right? Other commenters have shown examples of non-SQL relational databases. However, all the alternatives were also examples of Structured Query Languages. Languages designed to query a data store with _Structure_.

mamcx 5y ago

One branch that was super-popular in the day was the dbase family (I work in FoxPro, it was THE dream). Working in Fox dispel many of the weird limitations of sql (and BTW, you can use SQL on Fox alike linq, is first-class). The #1? You can build ALL using the relational model. After MS kill Fox my career can be summarized as: Trying N workarounds because I don't have Fox anymore. Other langs (python, delphi, f#, rust) capture a little of the magic or make the workaround bearable, but none is as productive.

vaughan 5y ago

SQL is simply converted into a logical relation algebra tree. So anything that can do that could be used. It's a shame that PSQL doesn't provide an API for this, then all the quirks of SQL could be fixed. However, then we would probably have a proliferation of non-standard SQL like what happened with JavaScript, and standard tooling couldn't be used. SQL is somewhat nice because its fairly well standardized.