4 ms·

Whenever I stumble on an article like that, I can't stop wondering why do so many developers think that SQL is hard/clunky in comparaison? (any article where

Whenever I stumble on an article like that*, I can't stop wondering why do so many developers think that SQL is hard/clunky in comparaison? *(any article where author seemingly rebuild a database engine from scratch with maybe 0,1% to 1% of features count present in any RDBMS including sqlite)

TuringTest 4y ago
> why do so many developers think that SQL is hard/clunky in comparison? > A database introduces a different data model - I have to translate between database data-types and my programming languages native data-types. The key concept is explained in this sentence in the article. It doesn't matter how difficult or simple it is; the problem is that it's a different model, so it creates translation inefficiencies and makes it more difficult to reason about. The object-relational impedance mismatch is a known problem; having data in one place and format, accessed through a single programming model will typically be easier than a separate service with a different language and model, no matter how efficient.
- RobotToaster 4y ago
  (my)Sql in itself can be quite powerful, although it seems it's advanced features are underused. I wonder about going the other way, and turning SQL into a full scripting language.
  - TuringTest 4y ago
    > turning SQL into a full scripting language That's what PL/SQL and T-SQL basically are. They work, but they have a somewhat weird programming model, halfway between programming and declarative sql but being neither, with table cursors and stateful SQL queries. And of course, their scope is limited to interacting with the database itself, not the outer world.
  - ttfkam 4y ago
    Partial list for Postgres: • pl/pgsql (a pl/sql clone) • pl/perl • pl/python • pl/v8 (JS, LiveScript, and CoffeeScript) • pl/java • pl/r • pl/lua • pl/rust • pl/ruby • pl/sh • pl/scheme • pl/julia Or at least that's where you can define arbitrary procedural/functional logic for result sets within a language oriented toward set theory and transformation.
- JodieBenitez 4y ago
  > no matter how efficient Well... these things matter a lot !
  - TuringTest 4y ago
    It does matter, but then it doesn't, if it makes your life as a programmer more difficult, which is the situation described here. SQL lives on because it makes database storage extremely efficient, not because developers enjoy switching context to an entirely different programming language and runtime environment. That they have to use it doesn't mean they have to like using it.
    - ttfkam 4y ago
      HTML is one context. CSS becomes a context switch with a different mental model. JS becomes another. Backend in Python, Java, PHP, etc. becomes another. Access via GraphQL, grpc, REST, etc. is yet another. SQL just adds one more to the list for that distinct problem domain. If you don't like SQL, that's not something universal to all devs nor due to the context switch. You either don't know SQL as well or just don't like it. That's fine, just not something to apply categorical terms that apply to "developers". If you can orient your mind to related sets and subsets, all other languages (and especially ORMs) start looking like square pegs for round holes. (I'm a developer who happens to like SQL's round peg quite a lot.) Imagine craftspeople complaining they hate using the tool perfectly suited to a particular task. "I'd prefer to use this hammer against the handle of the screwdriver to smooth out this wood, because I hate the context switch to using the planer, and I'm just more comfortable with hammers and screwdrivers."
      - namaria 4y ago
        I really don't get why some people in software are so invested in the tooling they use as part of their identity.
    - JodieBenitez 4y ago
      I happen to like SQL but maybe I've been doing this for too long. Still: > having data in one place and format, accessed through a single programming model will typically be easier than a separate service with a different language and model, no matter how efficient. I would need examples of such a system. The closest I know of is... a RDBMS coupled with a decent ORM.
Kuinox 4y ago
Same author made a good article exactly about this: https://www.scattered-thoughts.net/writing/against-sql https://www.scattered-thoughts.net/writing/against-sql
- ttfkam 4y ago
  Ever hear the advice, "Beware the old man in a young man's game"? Every couple of years a new upstart claims some fundamental flaw and illustrates how they would fix it. The industry has a lot of upheaval with new leaders emerging from the pack constantly. But after almost fifty years, SQL is still there. Folks have ORM'd it countless times. Tried to apply it to their popular (and unpopular) language. Implemented new database styles with novel access methods. And SQL is still just as strong if not stronger than ever. So either everyone just goes along with the old man out of habit despite the prospect of tremendous personal gain and advancement… …or there's something important (or many things) the young upstarts just aren't recognizing about that old man—to their peril.
  - Kuinox 4y ago
    The author has several points any developer experienced with SQL would have noticed or agree with. Author here is far from being a "youngster" and has worked severals years maintening/improving RDBS.
    - ttfkam 4y ago
      Young upstarts refers to the proposed replacement technology, not the man. SQL, the language, is the old man in a young man's game.
TeMPOraL 4y ago
Relational databases are lovely! SQL is... clunky, but it's still a wonderful way of working with data, compared to hand-rolling imperative loops or functional transforms. I've been thinking about this a lot in the past ~5 years. My current dream is not that we should be using SQL and RDBMS-es more in our systems, but the inverse: we should have relational database facilities built directly into our programming languages. Because when I look at the code I typically work with from a data processing angle, a lot of it is just hand-rolling small pieces of a relational database. I'm talking small scale here. That random business object storing two maps and wrapping them in a domain-specific API? That's two tables with two columns each, possibly connected with something else by their primary keys. Or two tables you always JOIN in a specific way. Or really just one table. But instead of encoding this understanding directly, we write the lower-level implementation of it - two maps to store data (prematurely baking in an indexing strategy), and relations left implicit, smeared across the object's methods.
- cgh 4y ago
  You might be interested in data-oriented design, nicely described in this talk by Andrew Kelley: https://vimeo.com/649009599 https://vimeo.com/649009599 Treating data in code using the same basic layout that databases use is common in game programming. The usual example is structs of arrays as opposed to arrays of structs. https://en.wikipedia.org/wiki/Data-oriented_design https://en.wikipedia.org/wiki/Data-oriented_design but I suggest watching the above talk first.
narag 4y ago
To be fair, it seems to me that the main idea of the article is different and more interesting than that. SQL hate is just a collateral.
pyrale 4y ago
Imo there is a big difference between RDBs as a store of data, in which you're trapped by past modeling decisions and a query language that constrains you, and SQL as a query language which is decent enough. SQL feels much better when you populate your DB with data from elsewhere, and use it as a tool to explore data you structured for your own purpose than it is when you try to ask questions to a model unfit for your purpose.
gspencley 4y ago
I will second the commenter who said that relational databases are lovely but SQL is clunky. I'll take it a step further and say that SQL is a design flaw imposed on us by large database vendors that we have been paying the price for for the past 50 years. There is a principle, included in SOLID, called "interface segregation" and it is the idea that having many, smaller, special-purposes interfaces is preferable to having fewer, larger more general-purpose interfaces. To understand the principle complete, just think about the differences between a consumer toaster oven and the cockpit of a Boeing 747 jet airplane. One can be operated by a five year-old (with supervision) while the other requires years of training and specialized domain knowledge to operate. In software, you can't get any more "general purpose" than a programming language. Consider the complexity that SQL has brought us over the past half a century: SQL injection vulnerabilities, object relational mappers, complex and computationally-expensive queries that are difficult to understand let alone optimize, business logic hidden inside of stored procedures and on and on we go. Basically all of the problems and challenges that are inherent in any kind of human-crafted code can be found inside of SQL and it is just an interface in front of a data storage / persistence engine. That doesn't mean that SQL is the most challenging language to learn and master. It just means that we have taken something special purpose (data persistence) and stuck a very general purpose interface in front of it with all of the complexity that doing so invites.
- ttfkam 4y ago
  You think SQL injection vulnerabilities are due to the SQL language itself? That's like saying JS is flawed specifically because too many people used eval(…).
  - gspencley 4y ago
    Your comment misses my broader point, which is that you don't NEED a text-based programming language to interface with a persistence engine. And so through that lens, yeah it's pretty obvious that if SQL didn't exist then neither would SQL injection vulnerabilities. That doesn't mean that an alternative interface wouldn't have its own potential attack vectors. It's just one example of the complexity invited and brought upon us by using a general purpose text-based programming language to interface with storage.

Whenever I stumble on an article like that*, I can't stop wondering why do so many developers think that SQL is hard/clunky in comparaison? *(any article where

TuringTest 4y ago

> why do so many developers think that SQL is hard/clunky in comparison? > A database introduces a different data model - I have to translate between database data-types and my programming languages native data-types. The key concept is explained in this sentence in the article. It doesn't matter how difficult or simple it is; the problem is that it's a different model, so it creates translation inefficiencies and makes it more difficult to reason about. The object-relational impedance mismatch is a known problem; having data in one place and format, accessed through a single programming model will typically be easier than a separate service with a different language and model, no matter how efficient.

RobotToaster 4y ago
(my)Sql in itself can be quite powerful, although it seems it's advanced features are underused. I wonder about going the other way, and turning SQL into a full scripting language.
- TuringTest 4y ago
  > turning SQL into a full scripting language That's what PL/SQL and T-SQL basically are. They work, but they have a somewhat weird programming model, halfway between programming and declarative sql but being neither, with table cursors and stateful SQL queries. And of course, their scope is limited to interacting with the database itself, not the outer world.
- ttfkam 4y ago
  Partial list for Postgres: • pl/pgsql (a pl/sql clone) • pl/perl • pl/python • pl/v8 (JS, LiveScript, and CoffeeScript) • pl/java • pl/r • pl/lua • pl/rust • pl/ruby • pl/sh • pl/scheme • pl/julia Or at least that's where you can define arbitrary procedural/functional logic for result sets within a language oriented toward set theory and transformation.
JodieBenitez 4y ago
> no matter how efficient Well... these things matter a lot !
- TuringTest 4y ago
  It does matter, but then it doesn't, if it makes your life as a programmer more difficult, which is the situation described here. SQL lives on because it makes database storage extremely efficient, not because developers enjoy switching context to an entirely different programming language and runtime environment. That they have to use it doesn't mean they have to like using it.
  - ttfkam 4y ago
    HTML is one context. CSS becomes a context switch with a different mental model. JS becomes another. Backend in Python, Java, PHP, etc. becomes another. Access via GraphQL, grpc, REST, etc. is yet another. SQL just adds one more to the list for that distinct problem domain. If you don't like SQL, that's not something universal to all devs nor due to the context switch. You either don't know SQL as well or just don't like it. That's fine, just not something to apply categorical terms that apply to "developers". If you can orient your mind to related sets and subsets, all other languages (and especially ORMs) start looking like square pegs for round holes. (I'm a developer who happens to like SQL's round peg quite a lot.) Imagine craftspeople complaining they hate using the tool perfectly suited to a particular task. "I'd prefer to use this hammer against the handle of the screwdriver to smooth out this wood, because I hate the context switch to using the planer, and I'm just more comfortable with hammers and screwdrivers."
    - namaria 4y ago
      I really don't get why some people in software are so invested in the tooling they use as part of their identity.
  - JodieBenitez 4y ago
    I happen to like SQL but maybe I've been doing this for too long. Still: > having data in one place and format, accessed through a single programming model will typically be easier than a separate service with a different language and model, no matter how efficient. I would need examples of such a system. The closest I know of is... a RDBMS coupled with a decent ORM.

Kuinox 4y ago

Same author made a good article exactly about this: https://www.scattered-thoughts.net/writing/against-sql https://www.scattered-thoughts.net/writing/against-sql

ttfkam 4y ago
Ever hear the advice, "Beware the old man in a young man's game"? Every couple of years a new upstart claims some fundamental flaw and illustrates how they would fix it. The industry has a lot of upheaval with new leaders emerging from the pack constantly. But after almost fifty years, SQL is still there. Folks have ORM'd it countless times. Tried to apply it to their popular (and unpopular) language. Implemented new database styles with novel access methods. And SQL is still just as strong if not stronger than ever. So either everyone just goes along with the old man out of habit despite the prospect of tremendous personal gain and advancement… …or there's something important (or many things) the young upstarts just aren't recognizing about that old man—to their peril.
- Kuinox 4y ago
  The author has several points any developer experienced with SQL would have noticed or agree with. Author here is far from being a "youngster" and has worked severals years maintening/improving RDBS.
  - ttfkam 4y ago
    Young upstarts refers to the proposed replacement technology, not the man. SQL, the language, is the old man in a young man's game.

TeMPOraL 4y ago

Relational databases are lovely! SQL is... clunky, but it's still a wonderful way of working with data, compared to hand-rolling imperative loops or functional transforms. I've been thinking about this a lot in the past ~5 years. My current dream is not that we should be using SQL and RDBMS-es more in our systems, but the inverse: we should have relational database facilities built directly into our programming languages. Because when I look at the code I typically work with from a data processing angle, a lot of it is just hand-rolling small pieces of a relational database. I'm talking small scale here. That random business object storing two maps and wrapping them in a domain-specific API? That's two tables with two columns each, possibly connected with something else by their primary keys. Or two tables you always JOIN in a specific way. Or really just one table. But instead of encoding this understanding directly, we write the lower-level implementation of it - two maps to store data (prematurely baking in an indexing strategy), and relations left implicit, smeared across the object's methods.

cgh 4y ago
You might be interested in data-oriented design, nicely described in this talk by Andrew Kelley: https://vimeo.com/649009599 https://vimeo.com/649009599 Treating data in code using the same basic layout that databases use is common in game programming. The usual example is structs of arrays as opposed to arrays of structs. https://en.wikipedia.org/wiki/Data-oriented_design https://en.wikipedia.org/wiki/Data-oriented_design but I suggest watching the above talk first.

narag 4y ago

To be fair, it seems to me that the main idea of the article is different and more interesting than that. SQL hate is just a collateral.

pyrale 4y ago

Imo there is a big difference between RDBs as a store of data, in which you're trapped by past modeling decisions and a query language that constrains you, and SQL as a query language which is decent enough. SQL feels much better when you populate your DB with data from elsewhere, and use it as a tool to explore data you structured for your own purpose than it is when you try to ask questions to a model unfit for your purpose.

gspencley 4y ago

I will second the commenter who said that relational databases are lovely but SQL is clunky. I'll take it a step further and say that SQL is a design flaw imposed on us by large database vendors that we have been paying the price for for the past 50 years. There is a principle, included in SOLID, called "interface segregation" and it is the idea that having many, smaller, special-purposes interfaces is preferable to having fewer, larger more general-purpose interfaces. To understand the principle complete, just think about the differences between a consumer toaster oven and the cockpit of a Boeing 747 jet airplane. One can be operated by a five year-old (with supervision) while the other requires years of training and specialized domain knowledge to operate. In software, you can't get any more "general purpose" than a programming language. Consider the complexity that SQL has brought us over the past half a century: SQL injection vulnerabilities, object relational mappers, complex and computationally-expensive queries that are difficult to understand let alone optimize, business logic hidden inside of stored procedures and on and on we go. Basically all of the problems and challenges that are inherent in any kind of human-crafted code can be found inside of SQL and it is just an interface in front of a data storage / persistence engine. That doesn't mean that SQL is the most challenging language to learn and master. It just means that we have taken something special purpose (data persistence) and stuck a very general purpose interface in front of it with all of the complexity that doing so invites.

ttfkam 4y ago
You think SQL injection vulnerabilities are due to the SQL language itself? That's like saying JS is flawed specifically because too many people used eval(…).
- gspencley 4y ago
  Your comment misses my broader point, which is that you don't NEED a text-based programming language to interface with a persistence engine. And so through that lens, yeah it's pretty obvious that if SQL didn't exist then neither would SQL injection vulnerabilities. That doesn't mean that an alternative interface wouldn't have its own potential attack vectors. It's just one example of the complexity invited and brought upon us by using a general purpose text-based programming language to interface with storage.