10 ms·

> except for a brief period in 2010 where we thought we could kill it Unfortunately, we never actually tried to kill SQL. We tried to kill relational databases

> except for a brief period in 2010 where we thought we could kill it Unfortunately, we never actually tried to kill SQL. We tried to kill relational databases, with the death of SQL as a side effect. This proved to be a stupid idea - non-relational data stores have value of course, but so do relational databases. SQL, as you point out, is 48 years old. It shows. The ergonomics are awful. It uses natural-language inspired syntax that has fallen completely out of favor (with good reason imho). The ordering of fields and tables precludes the use of autocomplete. It uses orthogonal syntax for identical constructions, i.e. INSERT ... (col1, col2, ...) VALUES (val1, val2, ...) vs. UPDATE ... col1=val1, col2=val2, ... And worst of all, it comes with such a woefully inadequate standard that half of the universally supported features are expressed in a completely different fashion for each vendor. It is very common to argue that its longevity is due to its excellence as a language. I think it's longevity is due to its broad target audience, which includes plenty of people in less technical roles who are high on the org chart. Tech workers are happy to jump on new technology that improves ergonomics (or shiny new toys that are strictly more interesting because they are new). Executives who's primary way of interacting with the tech stack is querying a read only replica are much less open to learning a new language.

lelanthran 4y ago
> It uses orthogonal syntax for identical constructions, i.e. Regarding your complaint ... those aren't identical constructions. Insert has to have the syntax it does because it lets you insert multiple rows all with different values in a single statement: INSERT ... (C1, C2) VALUES (v1, v2), (v3, v4), (v5, v6) Update doesn't allow that. The syntax for each of the above makes sense for the specific intention of each statement.
- aidos 4y ago
  And further, insert … (select …)
- RussianCow 4y ago
  They could have consolidated the syntax for both, though. No reason you couldn't have this instead: INSERT ... VALUES (C1=v1, C2=v2), (C1=v3, C2=v4), (C1=v5, C2=v6) This would actually be more powerful because it would allow you to arbitrarily omit columns on a per-row basis, which you can't do with SQL today.
  - smallnamespace 4y ago
    You can omit columns on a per-row basis with the DEFAULT keyword, it's just more cumbersome if your rows are very sparse. Your proposed syntax of: INSERT ... VALUES (C1=v1, C2=v2), (C3=v3, C4=v4), (C5=v5, C6=v6) in standard SQL is INSERT ... (C1, C2, ... C6) VALUES (v1, v2, DEFAULT, DEFAULT, DEFAULT, DEFAULT), (DEFAULT, DEFAULT, v3, v4, DEFAULT, DEFAULT), ...
  - layer8 4y ago
    It would maybe be more powerful, but also less efficient. If you want to insert different sets of columns, you just use multiple INSERT statements. The point of the current syntax is to be able to efficiently bulk-insert many rows using the same set of columns. That set of columns needs to be validated and mapped to the internal offsets (or whatever) only once for inserting an arbitrarily large number of rows, instead of having to repeat that validation and preprocessing for each row.
    - NavinF 4y ago
      What a bizarre use case. I highly doubt your scheme performs better than just using PREPARE AS INSERT to create a prepared statement and execution plan on the database side. Or are we still generating SQL using string interpolation in 2022?
      - ipaddr 4y ago
        Most people have an orm between them and the database. Think bulk inserting into via the command why the format exists vs what you do in your language and/or framework.
duxup 4y ago
Hey man if SQL is so great why are people always trying to kill it??!?!? /s
sanderjd 4y ago
I think your last sentence gets at the crux of it. I think SQL is truly great for that use case of analytical queries over a read only database / data warehouse / parquet / whatever (ie. "OLAP" use cases). I think it's less great for the "OLTP" use cases. It still works fine, which is why it sticks around, but other approaches are more convenient for doing lots of smaller inserts, updates, and lookups and fewer table scans and aggregations.
xwolfi 4y ago
I disagree, the people high on the org chart are clamouring for cloud-based low structure stores on microsoft azure cloud maintained in India, while we warn them that we can migrate at a giant cost for a net loss in efficiency. SQL and dbs are fine, they work, we could discuss beautifying sql for sure, but frankly we shouldnt solving data structuring problems that were already solved 50 years ago: we have real business to support instead.
denysonique 4y ago
> It uses orthogonal syntax for identical constructions There is an alternative INSERT syntax matching the UPDATE SET one: INSERT INTO table SET col1='val1', col2='val2';
- remram 4y ago
  The SELECT syntax is the one that's backwards IMHO (and that order hurts autocomplete too).
doctor_eval 4y ago
You can always do update t set (x, y) = (n, m); At least you can in more recent versions of Postgres, and I think it’s standard SQL.
emmelaich 4y ago
I hope that those two syntaxes could be unified in some future version. Also, surely allowing FROM and SELECT clauses to be swapped in order shouldn't stress out any parser too much.
- wruza 4y ago
  FROM and all subsequent JOINs, to be precise. They all generate a single namespace which SELECT uses. As far as I understand the grammar, FROM isn’t even a separate clause, but is itself a separator between a columnset and an expression of the form `t1 JOIN t2 ON cond12 JOIN t3 ON cond123 JOIN …`, where t<n> may be either a table name, or an arbitrarily nested subexpression of the same form.
Aeolun 4y ago
> The ergonomics are awful. It uses natural-language inspired syntax that has fallen completely out of favor I think SQL is so popular and has staying power for the same reason that our ridiculous gregorian calendar has staying power.
ahallock 4y ago
> SQL, as you point out, is 48 years old. It shows. That's irrelevant and a fallacy. Plenty of amazing things are old and have stood the test of time. Vim and SQL have empowered me my entire career.
dragonwriter 4y ago
> Unfortunately, we never actually tried to kill SQL. We tried to kill relational databases, with the death of SQL as a side effect. I don’t know who “we” is, but, before NoSQL tried to replace RDBMS(well, starting before, these things overlapped it), there were efforts to provide alternatives to SQL for RDBMSs, some examples: Query-by-Example. https://en.wikipedia.org/wiki/Query_by_Example https://en.wikipedia.org/wiki/Query_by_Example the D class of data languages. https://en.wikipedia.org/wiki/D_(data_language_specification) https://en.wikipedia.org/wiki/D_(data_language_specification...
ako 4y ago
The reason we can't replace SQL is that it is the lingua franca between many client tools and data sources. From programming languages, to Analytics tools, to ETL tools to bulk data transfer tools, everything knows how to define SQL queries. On the datastorage side, almost everything is standardizing on SQL as its API: RDBMSes, but also NoSQL storage (etc, hadoop + hive, etc), data virtualization layers (denodo, aws athena, steam pipe). You can't change this by providing a better query language in one of the datasource products, or by providing a better ORM. Because of the network effects it will be very hard to come up with something better that is universally adopted. Many have tried though but it's always limited to a small stack: MDX, DAX, Linq, Dplyr, Graphql, etc. There may be opportunities to replace SQL as soon as we need something that moves away from relational algebra. Currently you see al lot of adoption on graph storage and graph query languages in the Data Fabric space, as users need to build queries reasoning about relationships between different datasets in the enterprise. The other reason Data Fabrics could offer an opportunity here is that they're basically adding an layer of abstraction between all data sources and data consumers, and they the possibility to translate SQL into something else, e.g. graphql.
matwood 4y ago
I've been using SQL for ~25 years and don't think the ergonomics are nearly as bad as people say. In your example the insert is done that way for good reason. I know people hate listing the fields before the tables, but when I deal with data that's how I tend to think. I need X, Y, Z, now where do I get it from and do I need to filter. From a vendor standpoint, it can take time getting new standards implemented, but it's definitely not half. One of the big issues here is that MySQL was and still is in some ways woefully inadequate. It's shortcomings are also often make people think they are relational database shortcomings in general.
aabbcc1241 4y ago
The ergonomics issue of SQL can be workaround by transpiler. I do like SQL the syntax but it's hard to discard the ecosystem around SQL. For instance, I made better-sql [1] recently which generate SQL from a language similar to GraphQL and EdgeDB query language. [1] https://better-sql.surge.sh https://better-sql.surge.sh
wyager 4y ago
I have plenty of beef with SQL, but your insert versus update example doesn't make sense to me. That's a perfectly reasonable difference; insert is always a dense operation while update is usually a sparse operation.
- deleted 4y ago
  [deleted]
- netule 4y ago
  It's also the simplest use case of INSERT imaginable and fails to be applicable with a slightly more complex one: INSERT INTO table1 (col_1, col_2, col3) SELECT COUNT(col_6), col_4, col_5 FROM table2 INNER JOIN...
  - dllthomas 4y ago
    I think in principle we could allow INSERT INTO table1 col_1 = COUNT(table2.col_6), col_2 = table2.col_4, col3 = table2.col_5 FROM table2 INNER JOIN ...
jayd16 4y ago
I also feel like part of the staying power of SQL is because it's the lingua franca of the database. I wonder if it's time to build and popularize some lower level language that could be targeted by ORMs and others to speak to DB engines. If we had a more flexible assembly language we might get more freedom at the programmer language level.
- scarface74 4y ago
  C# already does that, it converts LINQ to expression trees that are then converted by providers to their target query language. I’ve used it on one project to pass around the same query expressions to SQL server and Mongo - you pass a type of IQueryable<T> which represents an expression tree. For instance var seniors = query(from u in Users where u.Age > 65 && u.Sex == “male” select u) IEnumerable<Users> query(IQueryable<Users>)
- johannes1234321 4y ago
  MySQL has something in that direction, where some operations can be expressed as expression trees by using Protobuf where a client can put some arbitrary query language on top: https://dev.mysql.com/doc/internals/en/x-protocol-messages-messages.html https://dev.mysql.com/doc/internals/en/x-protocol-messages-m... it is still a bit limited, though (like no join ...)
levkk 4y ago
SQL expresses relational algebra [0] which is the language defining data relationships and manipulation. It hasn't changed in 50 years for the same reason why B-Trees and sorting algorithms haven't: it's foundational to computer science. Database-specific "SQL extensions" are in my experience just administration commands, e.g. `VACUUM` or `CREATE EXTENSION` in Postgres. They help operate the DB, but have little to do with the actual data manipulation. Killing SQL is like trying to kill computer science: you better come up with something better than a synonym. [0] https://en.wikipedia.org/wiki/Relational_algebra https://en.wikipedia.org/wiki/Relational_algebra
- bryanrasmussen 4y ago
  >Killing SQL is like trying to kill computer science SQL is a language that expresses relational algebra, killing it is like killing any other language i.e. nearly impossible because there is still code sitting around written in it, thus needing competent programmers to maintain, competent programmers who will be asked to write more code and will choose to do it in SQL if they can get away with it, rinse and repeat and so forth. Once a language has a certain installed base it may be eternal - what size that installed base is I don't know.
  - bb88 4y ago
    The installed base is kind red herring, because most of the worlds largest companies use Oracle to hold their data. So you'd have to get Oracle on board. Could there be a better alternative, oh yes, most certainly. E.g. Every company I worked for needed to do SQL migrations. Unfortunately that isn't a part of SQL. Could it be? Yes! Is it? No! So everyone re-invents the wheel...
- blacklight 4y ago
  Db-specific extensions unfortunately aren't only admin commands. They include the whole PL/SQL thing, with concepts like triggers and stored procedures that should definitely be fundamental in SQL, but that nobody bothered to standardize, and eventually everybody implemented as they liked.
mfashby 4y ago
No mention of PRQL yet, it's an effort to tackle some of these shortcomings https://prql-lang.org/ https://prql-lang.org/
- lofaszvanitt 4y ago
  Which is plain terrible and unnecessary. SQL works, it's easy to understand, doesn't need any kind of abstractions or stupefying measures like PRQL.
mastersummoner 4y ago
When I was first learning to code, I once told someone that working with SQL felt like trying to wrestle with a mainframe, and I stand by that assertion.
omegalulw 4y ago
You are selling SQL way short. SQL has stuck around because, compared to its complexity, it lets you do incredibly powerful things.
- duxup 4y ago
  It's also great that much of the time if I come up with a crappy query... SQL knows how to optimize it for me. Easy to use, and fixes my stupids.
  - OJFord 4y ago
    That's nothing to do with SQL, that's the database engine you're using (lexing, parsing, then) planning & optimising your query as best it can. Much like C code say, it's not a feature of C the language that gcc, for example, can optimise your crappy code for whatever target platform.
- strbean 4y ago
  Look at the analogy to general purpose programming languages. Every single one, without exception, lets you do incredibly powerful things compared to its complexity. This hasn't stopped the progression of general purpose programming languages, and I think the vast majority of developers would agree that there have been huge improvements in the last 50 years.
  - doctor_eval 4y ago
    TIOBE [0] reckons that the top 10 programming languages are currently Python, C, Java, C++, C#, Visual Basic, JavaScript, "Assembly Language", SQL and PHP. The first five languages represent more than 50% of the users in TIOBE. Apart from SQL, all of these languages are imperative, and most of them derive from C in some shape or form; K&R C was published in 1978, 44 years ago. So, while I'd agree that there have certainly been huge incremental improvements in imperative programming in the last ~50 years, when we look at what people use on a daily basis, it's not really clear to me that the changes have been any greater in significance than the changes that SQL has gone through during the same period. [0] https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/
codegeek 4y ago
To my primitive brain, NoSQL always sounded like "I am going to makeup data model and integrity on the fly and let the user figure out how to handle it". No Thanks. But may be I don't get it. GraphQL honestly gives me the same vibes. Happy to be corrected.
- catlifeonmars 4y ago
  Just to be pedantic you can use SQL to query NoSQL databases, just look at the PartiQL ExecuteStatement API for DynamoDB. I assume your question is about why anyone would use a NoSQL databases instead of a relational database. The short answer is scale. If you have well define access patterns that rely only on a primary index, you can effectively scale to billions of QPS. If you want to make relational queries, and/or can’t know your access patterns in advance, use a relational database.
- xapata 4y ago
  Sometimes you just want to store data and worry about validation later. I'm in that situation now, with different tasks requiring different kinds of validation for the same data. Sometimes I want all the postal codes that users have entered, sometimes I want only the valid postal codes.
- RussianCow 4y ago
  > GraphQL honestly gives me the same vibes. Not that this is particularly relevant to the discussion, but GraphQL is actually much closer to SQL than most NoSQL solutions because it's statically typed and the schema is statically defined. The GraphQL schema acts as the contract of what the API can serve to the client, much like a schema in a relational database.
- blagie 4y ago
  "Replacements" for SQL have been around as long as SQL. Remember the OODBMS rage of the eighties and nineties? https://en.wikipedia.org/wiki/Object_database https://en.wikipedia.org/wiki/Object_database I also wanted to kill old, obsolete, crummy SQL when I first learned it as a teenager. It reminded me of FORTRAN or COBAL or something. It took quite a lot of theory and maturity to understand why RDBMS is the right paradigm. SQL is imperfect, but it's good enough to not be worth replacing. Whenever I've seen benchmarks of postgresql managing JSON versus mongodb, postgresql won (at least comparing apples-to-apples; postgresql is much more conservative by default, in terms of reliability and data consistency, than mongodb). There's literally no reason to going with a lot of NoSQL databases over using a SQL database as a key-value store.

lelanthran 4y ago

> It uses orthogonal syntax for identical constructions, i.e. Regarding your complaint ... those aren't identical constructions. Insert has to have the syntax it does because it lets you insert multiple rows all with different values in a single statement: INSERT ... (C1, C2) VALUES (v1, v2), (v3, v4), (v5, v6) Update doesn't allow that. The syntax for each of the above makes sense for the specific intention of each statement.

aidos 4y ago
And further, insert … (select …)
RussianCow 4y ago
They could have consolidated the syntax for both, though. No reason you couldn't have this instead: INSERT ... VALUES (C1=v1, C2=v2), (C1=v3, C2=v4), (C1=v5, C2=v6) This would actually be more powerful because it would allow you to arbitrarily omit columns on a per-row basis, which you can't do with SQL today.
- smallnamespace 4y ago
  You can omit columns on a per-row basis with the DEFAULT keyword, it's just more cumbersome if your rows are very sparse. Your proposed syntax of: INSERT ... VALUES (C1=v1, C2=v2), (C3=v3, C4=v4), (C5=v5, C6=v6) in standard SQL is INSERT ... (C1, C2, ... C6) VALUES (v1, v2, DEFAULT, DEFAULT, DEFAULT, DEFAULT), (DEFAULT, DEFAULT, v3, v4, DEFAULT, DEFAULT), ...
- layer8 4y ago
  It would maybe be more powerful, but also less efficient. If you want to insert different sets of columns, you just use multiple INSERT statements. The point of the current syntax is to be able to efficiently bulk-insert many rows using the same set of columns. That set of columns needs to be validated and mapped to the internal offsets (or whatever) only once for inserting an arbitrarily large number of rows, instead of having to repeat that validation and preprocessing for each row.
  - NavinF 4y ago
    What a bizarre use case. I highly doubt your scheme performs better than just using PREPARE AS INSERT to create a prepared statement and execution plan on the database side. Or are we still generating SQL using string interpolation in 2022?
    - ipaddr 4y ago
      Most people have an orm between them and the database. Think bulk inserting into via the command why the format exists vs what you do in your language and/or framework.

duxup 4y ago

Hey man if SQL is so great why are people always trying to kill it??!?!? /s

sanderjd 4y ago

I think your last sentence gets at the crux of it. I think SQL is truly great for that use case of analytical queries over a read only database / data warehouse / parquet / whatever (ie. "OLAP" use cases). I think it's less great for the "OLTP" use cases. It still works fine, which is why it sticks around, but other approaches are more convenient for doing lots of smaller inserts, updates, and lookups and fewer table scans and aggregations.

xwolfi 4y ago

I disagree, the people high on the org chart are clamouring for cloud-based low structure stores on microsoft azure cloud maintained in India, while we warn them that we can migrate at a giant cost for a net loss in efficiency. SQL and dbs are fine, they work, we could discuss beautifying sql for sure, but frankly we shouldnt solving data structuring problems that were already solved 50 years ago: we have real business to support instead.

denysonique 4y ago

> It uses orthogonal syntax for identical constructions There is an alternative INSERT syntax matching the UPDATE SET one: INSERT INTO table SET col1='val1', col2='val2';

remram 4y ago
The SELECT syntax is the one that's backwards IMHO (and that order hurts autocomplete too).

doctor_eval 4y ago

You can always do update t set (x, y) = (n, m); At least you can in more recent versions of Postgres, and I think it’s standard SQL.

emmelaich 4y ago

I hope that those two syntaxes could be unified in some future version. Also, surely allowing FROM and SELECT clauses to be swapped in order shouldn't stress out any parser too much.

wruza 4y ago
FROM and all subsequent JOINs, to be precise. They all generate a single namespace which SELECT uses. As far as I understand the grammar, FROM isn’t even a separate clause, but is itself a separator between a columnset and an expression of the form `t1 JOIN t2 ON cond12 JOIN t3 ON cond123 JOIN …`, where t<n> may be either a table name, or an arbitrarily nested subexpression of the same form.

Aeolun 4y ago

> The ergonomics are awful. It uses natural-language inspired syntax that has fallen completely out of favor I think SQL is so popular and has staying power for the same reason that our ridiculous gregorian calendar has staying power.

ahallock 4y ago

> SQL, as you point out, is 48 years old. It shows. That's irrelevant and a fallacy. Plenty of amazing things are old and have stood the test of time. Vim and SQL have empowered me my entire career.

dragonwriter 4y ago

> Unfortunately, we never actually tried to kill SQL. We tried to kill relational databases, with the death of SQL as a side effect. I don’t know who “we” is, but, before NoSQL tried to replace RDBMS(well, starting before, these things overlapped it), there were efforts to provide alternatives to SQL for RDBMSs, some examples: Query-by-Example. https://en.wikipedia.org/wiki/Query_by_Example https://en.wikipedia.org/wiki/Query_by_Example the D class of data languages. https://en.wikipedia.org/wiki/D_(data_language_specification) https://en.wikipedia.org/wiki/D_(data_language_specification...

ako 4y ago

The reason we can't replace SQL is that it is the lingua franca between many client tools and data sources. From programming languages, to Analytics tools, to ETL tools to bulk data transfer tools, everything knows how to define SQL queries. On the datastorage side, almost everything is standardizing on SQL as its API: RDBMSes, but also NoSQL storage (etc, hadoop + hive, etc), data virtualization layers (denodo, aws athena, steam pipe). You can't change this by providing a better query language in one of the datasource products, or by providing a better ORM. Because of the network effects it will be very hard to come up with something better that is universally adopted. Many have tried though but it's always limited to a small stack: MDX, DAX, Linq, Dplyr, Graphql, etc. There may be opportunities to replace SQL as soon as we need something that moves away from relational algebra. Currently you see al lot of adoption on graph storage and graph query languages in the Data Fabric space, as users need to build queries reasoning about relationships between different datasets in the enterprise. The other reason Data Fabrics could offer an opportunity here is that they're basically adding an layer of abstraction between all data sources and data consumers, and they the possibility to translate SQL into something else, e.g. graphql.

matwood 4y ago

I've been using SQL for ~25 years and don't think the ergonomics are nearly as bad as people say. In your example the insert is done that way for good reason. I know people hate listing the fields before the tables, but when I deal with data that's how I tend to think. I need X, Y, Z, now where do I get it from and do I need to filter. From a vendor standpoint, it can take time getting new standards implemented, but it's definitely not half. One of the big issues here is that MySQL was and still is in some ways woefully inadequate. It's shortcomings are also often make people think they are relational database shortcomings in general.

aabbcc1241 4y ago

The ergonomics issue of SQL can be workaround by transpiler. I do like SQL the syntax but it's hard to discard the ecosystem around SQL. For instance, I made better-sql [1] recently which generate SQL from a language similar to GraphQL and EdgeDB query language. [1] https://better-sql.surge.sh https://better-sql.surge.sh

wyager 4y ago

I have plenty of beef with SQL, but your insert versus update example doesn't make sense to me. That's a perfectly reasonable difference; insert is always a dense operation while update is usually a sparse operation.

deleted 4y ago
[deleted]
netule 4y ago
It's also the simplest use case of INSERT imaginable and fails to be applicable with a slightly more complex one: INSERT INTO table1 (col_1, col_2, col3) SELECT COUNT(col_6), col_4, col_5 FROM table2 INNER JOIN...
- dllthomas 4y ago
  I think in principle we could allow INSERT INTO table1 col_1 = COUNT(table2.col_6), col_2 = table2.col_4, col3 = table2.col_5 FROM table2 INNER JOIN ...

jayd16 4y ago

I also feel like part of the staying power of SQL is because it's the lingua franca of the database. I wonder if it's time to build and popularize some lower level language that could be targeted by ORMs and others to speak to DB engines. If we had a more flexible assembly language we might get more freedom at the programmer language level.

scarface74 4y ago
C# already does that, it converts LINQ to expression trees that are then converted by providers to their target query language. I’ve used it on one project to pass around the same query expressions to SQL server and Mongo - you pass a type of IQueryable<T> which represents an expression tree. For instance var seniors = query(from u in Users where u.Age > 65 && u.Sex == “male” select u) IEnumerable<Users> query(IQueryable<Users>)
johannes1234321 4y ago
MySQL has something in that direction, where some operations can be expressed as expression trees by using Protobuf where a client can put some arbitrary query language on top: https://dev.mysql.com/doc/internals/en/x-protocol-messages-messages.html https://dev.mysql.com/doc/internals/en/x-protocol-messages-m... it is still a bit limited, though (like no join ...)

levkk 4y ago

SQL expresses relational algebra [0] which is the language defining data relationships and manipulation. It hasn't changed in 50 years for the same reason why B-Trees and sorting algorithms haven't: it's foundational to computer science. Database-specific "SQL extensions" are in my experience just administration commands, e.g. `VACUUM` or `CREATE EXTENSION` in Postgres. They help operate the DB, but have little to do with the actual data manipulation. Killing SQL is like trying to kill computer science: you better come up with something better than a synonym. [0] https://en.wikipedia.org/wiki/Relational_algebra https://en.wikipedia.org/wiki/Relational_algebra

bryanrasmussen 4y ago
>Killing SQL is like trying to kill computer science SQL is a language that expresses relational algebra, killing it is like killing any other language i.e. nearly impossible because there is still code sitting around written in it, thus needing competent programmers to maintain, competent programmers who will be asked to write more code and will choose to do it in SQL if they can get away with it, rinse and repeat and so forth. Once a language has a certain installed base it may be eternal - what size that installed base is I don't know.
- bb88 4y ago
  The installed base is kind red herring, because most of the worlds largest companies use Oracle to hold their data. So you'd have to get Oracle on board. Could there be a better alternative, oh yes, most certainly. E.g. Every company I worked for needed to do SQL migrations. Unfortunately that isn't a part of SQL. Could it be? Yes! Is it? No! So everyone re-invents the wheel...
blacklight 4y ago
Db-specific extensions unfortunately aren't only admin commands. They include the whole PL/SQL thing, with concepts like triggers and stored procedures that should definitely be fundamental in SQL, but that nobody bothered to standardize, and eventually everybody implemented as they liked.

mfashby 4y ago

No mention of PRQL yet, it's an effort to tackle some of these shortcomings https://prql-lang.org/ https://prql-lang.org/

lofaszvanitt 4y ago
Which is plain terrible and unnecessary. SQL works, it's easy to understand, doesn't need any kind of abstractions or stupefying measures like PRQL.

mastersummoner 4y ago

When I was first learning to code, I once told someone that working with SQL felt like trying to wrestle with a mainframe, and I stand by that assertion.

omegalulw 4y ago

You are selling SQL way short. SQL has stuck around because, compared to its complexity, it lets you do incredibly powerful things.

duxup 4y ago
It's also great that much of the time if I come up with a crappy query... SQL knows how to optimize it for me. Easy to use, and fixes my stupids.
- OJFord 4y ago
  That's nothing to do with SQL, that's the database engine you're using (lexing, parsing, then) planning & optimising your query as best it can. Much like C code say, it's not a feature of C the language that gcc, for example, can optimise your crappy code for whatever target platform.
strbean 4y ago
Look at the analogy to general purpose programming languages. Every single one, without exception, lets you do incredibly powerful things compared to its complexity. This hasn't stopped the progression of general purpose programming languages, and I think the vast majority of developers would agree that there have been huge improvements in the last 50 years.
- doctor_eval 4y ago
  TIOBE [0] reckons that the top 10 programming languages are currently Python, C, Java, C++, C#, Visual Basic, JavaScript, "Assembly Language", SQL and PHP. The first five languages represent more than 50% of the users in TIOBE. Apart from SQL, all of these languages are imperative, and most of them derive from C in some shape or form; K&R C was published in 1978, 44 years ago. So, while I'd agree that there have certainly been huge incremental improvements in imperative programming in the last ~50 years, when we look at what people use on a daily basis, it's not really clear to me that the changes have been any greater in significance than the changes that SQL has gone through during the same period. [0] https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/

codegeek 4y ago

To my primitive brain, NoSQL always sounded like "I am going to makeup data model and integrity on the fly and let the user figure out how to handle it". No Thanks. But may be I don't get it. GraphQL honestly gives me the same vibes. Happy to be corrected.

catlifeonmars 4y ago
Just to be pedantic you can use SQL to query NoSQL databases, just look at the PartiQL ExecuteStatement API for DynamoDB. I assume your question is about why anyone would use a NoSQL databases instead of a relational database. The short answer is scale. If you have well define access patterns that rely only on a primary index, you can effectively scale to billions of QPS. If you want to make relational queries, and/or can’t know your access patterns in advance, use a relational database.
xapata 4y ago
Sometimes you just want to store data and worry about validation later. I'm in that situation now, with different tasks requiring different kinds of validation for the same data. Sometimes I want all the postal codes that users have entered, sometimes I want only the valid postal codes.
RussianCow 4y ago
> GraphQL honestly gives me the same vibes. Not that this is particularly relevant to the discussion, but GraphQL is actually much closer to SQL than most NoSQL solutions because it's statically typed and the schema is statically defined. The GraphQL schema acts as the contract of what the API can serve to the client, much like a schema in a relational database.
blagie 4y ago
"Replacements" for SQL have been around as long as SQL. Remember the OODBMS rage of the eighties and nineties? https://en.wikipedia.org/wiki/Object_database https://en.wikipedia.org/wiki/Object_database I also wanted to kill old, obsolete, crummy SQL when I first learned it as a teenager. It reminded me of FORTRAN or COBAL or something. It took quite a lot of theory and maturity to understand why RDBMS is the right paradigm. SQL is imperfect, but it's good enough to not be worth replacing. Whenever I've seen benchmarks of postgresql managing JSON versus mongodb, postgresql won (at least comparing apples-to-apples; postgresql is much more conservative by default, in terms of reliability and data consistency, than mongodb). There's literally no reason to going with a lot of NoSQL databases over using a SQL database as a key-value store.