5 ms·

> I've spent most of my career hoping that something - anything that's better than SQL will come along and replace it. So, if we put aside Clippy jokes and so

> I've spent most of my career hoping that something - anything that's better than SQL will come along and replace it. So, if we put aside Clippy jokes and so on, what's your problem with SQL exactly and what does "better than SQL" mean to you? Because what I saw in the last couple of decades is the NoSQL movement lose air, and half the products representing it adding some sort of SQL dialect support, which if you think about it is hilarious admission of defeat. SQL is exceptionally good at being a relational algebra language, and if you think in terms of relational algebra, you might find out there's nothing wrong with it, aside from superficial remarks like "FROM should come before SELECT".

BiteCode_dev 5y ago
It's super verbose, doesn't compose well with the host language primitives, is hard to introspect, full of gotchas and very low level.
- BulgarianIdiot 5y ago
  Databases have no "host" they have "clients" which are heterogenous. So directing this critique at SQL is completely unfounded. .NET added LINQ and now basic queries are integrated. It was not up to SQL, it was up to .NET And calling it "very low-level" makes me question if you understand what SQL does and is. It's probably the only mainstream 4th generation language I can think of. https://en.wikipedia.org/wiki/Fourth-generation_programming_language https://en.wikipedia.org/wiki/Fourth-generation_programming_...
  - BiteCode_dev 5y ago
    Host language, as in the language of your app that embeds some sql code, not host related to the db. The host language may or may not be the client language. It's low level because it lacks abstraction and anything outside the data query declarative paradigm is subpar. It has no notion of anything outside of itself, so it's a very restrictive inflexible dsl living in it's own bubble. And even worst, it lacks elegant abstractions for problems we've have had for decades, such as pagination, hierarchy, etc Also, using linq as an example rather shows your lack of understanding of the field of abstractions for sql. The state of the art ORM is currently SQLA, the leading innovation to replace sql as a dsl is edgeql, both are addressing sql pain points while aiming at allowing you to do all of what sql could do.
    - goto11 5y ago
      I think you use "low level" in a different sense than is common. Low level (and high level) typically refer to abstraction level. SQL certainly have a very high abstraction level. But given it is a domain specific language it doesn't have much support for functionality outside of its intended domain (except through non-standard extensions). But a kitchen-sink language is not automatically higher level than a highly focused DSL - typically it is the other way around.
- goto11 5y ago
  In what way is SQL "low level"? I would consider it a very high level DSL. Agree about the verbosity. The syntax is quite clunky.
  - BiteCode_dev 5y ago
    Higher level than C, sure. But compared to modern programming language, it lacks primitives, important abstractions, asks you to do many things manually and have way to many gotchas to be on par of what we consider high level in 2021.
strbean 5y ago
When I heard "NoSQL", I thought we were getting an alternative query language for working with relational data, not throwing away the entire concept of RBMS's.
- BulgarianIdiot 5y ago
  Every generation wants to rebel about something. Some rebel about really silly things, such as RDBMS.
  - cratermoon 5y ago
    To borrow a turn of phrase, the RDBMS is the best database technology going today, which is to say, it's the marginally acceptable one among the set of complete bagbiting loser database technologies that we have to work with out here in the real world.
sa46 5y ago
There's a lot wrong with SQL. Chris Date [1] wrote several books comparing SQL to a more pure implementation relational algebra, Tutorial D. In Date's words: > SQL is incapable of providing the kind of firm foundation we need for future growth and development. Instead, it’s the relational model that has to provide that foundation. [...] We see SQL as a kind of database COBOL, and we would like to see some other language become available as a better alternative to it. Summarizing Date's points: - Real relations don't contain duplicate tuples but SQL tables allow duplicate rows. - Tuples and therefore relations don't ever contain nulls. Personally, I have trouble understanding how to support this limitation given LEFT JOIN. - Domain types only provide type aliases not a new type. For example, you can compare or join on different domain types if the base type is the same. Date uses the example of `p.weight = sp.qty` to show a comparison on domain types that shouldn't be allowed. - SQL has many ways to express the same query. His example shows at least 12 ways to answer "Get part numbers for parts that either are screws or are supplied by supplier S1, or both." - SELECT DISTINCT should have been the default instead of SELECT ALL. My personal gripes: - SQL is quite chatty, so much so that you can omit words in some incantations. - It's hard to dynamically build queries. It composes poorly for anything dynamic, even simple things like ordering by a column name. [1]: https://en.wikipedia.org/wiki/Christopher_J._Date https://en.wikipedia.org/wiki/Christopher_J._Date
- BulgarianIdiot 5y ago
  It seems a lot of those things you list as "wrong" come from lack of understanding of the reasons behind these choices, and born out of pure idealism in vacuum. For example, allowing duplicate rows is irrelevant, because if you have a primary key, there are no duplicate rows. SQL doesn't require primary keys because relational algebra has no such concept as a "primary key". There are just keys. However without defining a primary key, enforcing unique rows would mean the database silently indexing the ENTIRE ROW'S CONTENTS, including potentially blobs and large text fields. This would obviously be nonsense. Likewise, having SELECT DISTINCT be a default would mean a very expensive processing step in your query processing being a default. An expensive step that in fact doesn't matter, because the vast majority of queries don't produce duplicate results in practice. DISTINCT is optional because the need for it is exceptional, and its cost is high. Even you don't buy the "have no NULL" argument. So I don't have to defend this. Real-world data is not perfectly "rectangular". Optional attributes are a thing. So having a primitive for it makes sense. Once again, SQL allows you to define a field as non-nullable, so complaining about it being there if you EXPLICITLY WANT IT is silly. Regarding having many ways to express the same query: that's true for all languages. This is one of the biggest issues in optimizing compilers, canonicalizing expressions so patterns can be recognized. There's no way to do it at the source, so complaining SQL also does it, is like shouting at clouds. Regarding the type system, type systems can always be better, but let's not forget type systems (typically) exist to eliminate mistakes, not to enable new features. The kind of mistake where you compare "weight and quantity" is not likely. More subtle errors are possible, like comparing metric and imperial measures, but since SQL is often used in tandem with a system's language (Java, C++) or a script, all this domain logic is offloaded to them and their type system. Even if SQL had a detailed type system, therefore, most people wouldn't bother duplicating their detailed type definitions from Java to SQL or back. The only remaining issue is SQL is chatty. Which is quite ironic given the procedural code for what SQL does would be several times the size of the SQL query. SQL is a high-level language, and it being explicit is fine. And few extra letters here and there for a keyword don't make or break a language. I prefer chatty over cryptic.
cratermoon 5y ago
- actual abstract data types - object (or rather, tuple) identity - replace null with something to indicate missing or unknown. Have sensible null object behavior And the big one that gives every relational algebra purist fits: make graph theory a first-class citizen of the data model.
cratermoon 5y ago
> half the products representing it adding some sort of SQL dialect support, which if you think about it is hilarious admission of defeat. I don't see that as an admission of defeat. I see that as an attempt to provide some of the things that are good about SQL without dragging in the entire hairball of the language. Along the way, by choosing which subset of SQL to emulate the designers get to incorporate programming concepts that have come along since SQL. Things like user-defined ADTs, lambda expressions, and extensibility. Oh wait, LISP had all those before relational algebra was a gleam in the eyes of Date & Codd.

BiteCode_dev 5y ago

It's super verbose, doesn't compose well with the host language primitives, is hard to introspect, full of gotchas and very low level.

BulgarianIdiot 5y ago
Databases have no "host" they have "clients" which are heterogenous. So directing this critique at SQL is completely unfounded. .NET added LINQ and now basic queries are integrated. It was not up to SQL, it was up to .NET And calling it "very low-level" makes me question if you understand what SQL does and is. It's probably the only mainstream 4th generation language I can think of. https://en.wikipedia.org/wiki/Fourth-generation_programming_language https://en.wikipedia.org/wiki/Fourth-generation_programming_...
- BiteCode_dev 5y ago
  Host language, as in the language of your app that embeds some sql code, not host related to the db. The host language may or may not be the client language. It's low level because it lacks abstraction and anything outside the data query declarative paradigm is subpar. It has no notion of anything outside of itself, so it's a very restrictive inflexible dsl living in it's own bubble. And even worst, it lacks elegant abstractions for problems we've have had for decades, such as pagination, hierarchy, etc Also, using linq as an example rather shows your lack of understanding of the field of abstractions for sql. The state of the art ORM is currently SQLA, the leading innovation to replace sql as a dsl is edgeql, both are addressing sql pain points while aiming at allowing you to do all of what sql could do.
  - goto11 5y ago
    I think you use "low level" in a different sense than is common. Low level (and high level) typically refer to abstraction level. SQL certainly have a very high abstraction level. But given it is a domain specific language it doesn't have much support for functionality outside of its intended domain (except through non-standard extensions). But a kitchen-sink language is not automatically higher level than a highly focused DSL - typically it is the other way around.
goto11 5y ago
In what way is SQL "low level"? I would consider it a very high level DSL. Agree about the verbosity. The syntax is quite clunky.
- BiteCode_dev 5y ago
  Higher level than C, sure. But compared to modern programming language, it lacks primitives, important abstractions, asks you to do many things manually and have way to many gotchas to be on par of what we consider high level in 2021.

strbean 5y ago

When I heard "NoSQL", I thought we were getting an alternative query language for working with relational data, not throwing away the entire concept of RBMS's.

BulgarianIdiot 5y ago
Every generation wants to rebel about something. Some rebel about really silly things, such as RDBMS.
- cratermoon 5y ago
  To borrow a turn of phrase, the RDBMS is the best database technology going today, which is to say, it's the marginally acceptable one among the set of complete bagbiting loser database technologies that we have to work with out here in the real world.

sa46 5y ago

There's a lot wrong with SQL. Chris Date [1] wrote several books comparing SQL to a more pure implementation relational algebra, Tutorial D. In Date's words: > SQL is incapable of providing the kind of firm foundation we need for future growth and development. Instead, it’s the relational model that has to provide that foundation. [...] We see SQL as a kind of database COBOL, and we would like to see some other language become available as a better alternative to it. Summarizing Date's points: - Real relations don't contain duplicate tuples but SQL tables allow duplicate rows. - Tuples and therefore relations don't ever contain nulls. Personally, I have trouble understanding how to support this limitation given LEFT JOIN. - Domain types only provide type aliases not a new type. For example, you can compare or join on different domain types if the base type is the same. Date uses the example of `p.weight = sp.qty` to show a comparison on domain types that shouldn't be allowed. - SQL has many ways to express the same query. His example shows at least 12 ways to answer "Get part numbers for parts that either are screws or are supplied by supplier S1, or both." - SELECT DISTINCT should have been the default instead of SELECT ALL. My personal gripes: - SQL is quite chatty, so much so that you can omit words in some incantations. - It's hard to dynamically build queries. It composes poorly for anything dynamic, even simple things like ordering by a column name. [1]: https://en.wikipedia.org/wiki/Christopher_J._Date https://en.wikipedia.org/wiki/Christopher_J._Date

BulgarianIdiot 5y ago
It seems a lot of those things you list as "wrong" come from lack of understanding of the reasons behind these choices, and born out of pure idealism in vacuum. For example, allowing duplicate rows is irrelevant, because if you have a primary key, there are no duplicate rows. SQL doesn't require primary keys because relational algebra has no such concept as a "primary key". There are just keys. However without defining a primary key, enforcing unique rows would mean the database silently indexing the ENTIRE ROW'S CONTENTS, including potentially blobs and large text fields. This would obviously be nonsense. Likewise, having SELECT DISTINCT be a default would mean a very expensive processing step in your query processing being a default. An expensive step that in fact doesn't matter, because the vast majority of queries don't produce duplicate results in practice. DISTINCT is optional because the need for it is exceptional, and its cost is high. Even you don't buy the "have no NULL" argument. So I don't have to defend this. Real-world data is not perfectly "rectangular". Optional attributes are a thing. So having a primitive for it makes sense. Once again, SQL allows you to define a field as non-nullable, so complaining about it being there if you EXPLICITLY WANT IT is silly. Regarding having many ways to express the same query: that's true for all languages. This is one of the biggest issues in optimizing compilers, canonicalizing expressions so patterns can be recognized. There's no way to do it at the source, so complaining SQL also does it, is like shouting at clouds. Regarding the type system, type systems can always be better, but let's not forget type systems (typically) exist to eliminate mistakes, not to enable new features. The kind of mistake where you compare "weight and quantity" is not likely. More subtle errors are possible, like comparing metric and imperial measures, but since SQL is often used in tandem with a system's language (Java, C++) or a script, all this domain logic is offloaded to them and their type system. Even if SQL had a detailed type system, therefore, most people wouldn't bother duplicating their detailed type definitions from Java to SQL or back. The only remaining issue is SQL is chatty. Which is quite ironic given the procedural code for what SQL does would be several times the size of the SQL query. SQL is a high-level language, and it being explicit is fine. And few extra letters here and there for a keyword don't make or break a language. I prefer chatty over cryptic.

cratermoon 5y ago

- actual abstract data types - object (or rather, tuple) identity - replace null with something to indicate missing or unknown. Have sensible null object behavior And the big one that gives every relational algebra purist fits: make graph theory a first-class citizen of the data model.

cratermoon 5y ago

> half the products representing it adding some sort of SQL dialect support, which if you think about it is hilarious admission of defeat. I don't see that as an admission of defeat. I see that as an attempt to provide some of the things that are good about SQL without dragging in the entire hairball of the language. Along the way, by choosing which subset of SQL to emulate the designers get to incorporate programming concepts that have come along since SQL. Things like user-defined ADTs, lambda expressions, and extensibility. Oh wait, LISP had all those before relational algebra was a gleam in the eyes of Date & Codd.