5 ms·

I'm probably one of those programmers you think "use SQL quite happily". You're wrong. SQL is an abstraction with myriad problems in both its core design and i

I'm probably one of those programmers you think "use SQL quite happily". You're wrong. SQL is an abstraction with myriad problems in both its core design and its disjointed implementations. ORMs and similar interfaces are crappy abstractions on top of a crappy abstraction. You get the problems of SQL combined with the problems of the ORM. Preferring to remove a set of problems and be left with only the problems of SQL is not the same thing as liking SQL, it is merely preferring the lesser of two evils.

mamcx 12y ago
In what sense SQL is bad?
- nknighthb 12y ago
  I see no reason to reproduce Wikipedia's laundry list: http://en.wikipedia.org/wiki/SQL#Criticism http://en.wikipedia.org/wiki/SQL#Criticism
  - jeltz 12y ago
    Wikipedia's laundry list contains of two items: * SQL not being relational algebra * SQL implementations being incompatible Both are real but I have not experienced either of these being a problem in real usage. Despite the problems caused by NULLs and that SQL allows duplicates I do not think the alternative would be better for real world programming. And the incompatibilities are avoided by picking one database per project and sticking with it.
    - nknighthb 12y ago
      Even if you reduce it to its most basic issues, you missed a third: Incompleteness of implementations. If you have not experienced problems as a result of these core issues, it honestly makes me feel you must not have a lot of experience -- at least not in diverse projects and environments. That you think picking one database is some sort of viable solution in the general case amplifies that feeling. That is so often simply not an option, and even where supporting only one database at a time is an option, you absolutely cannot guarantee that you will not have to migrate later. I've been through that pain many times, it is a real-world problem.
      - deleted 12y ago
        [deleted]
      - deleted 12y ago
        [deleted]
      - jeltz 12y ago
        I honestly think you should look at the database just like any other piece of your code, you cannot just replace GTK with WX Widgets and except there to be no migration work. And most of these differences between databases have nothing to do with SQL, but rather databases not implementing it correctly for legacy reasons. I would not expect a new database query language or NoSQL databases to do this better.
- Joeri 12y ago
  Well, I like SQL, but let me play devil's advocate and guess at some of the ways people may consider it "bad": - SQL queries flatten structured and hierarchical relationships into unstructured rows, often requiring very creative join operations to get at the exact set of data you want, after which you then have to convert everything back to the structured data you wanted in the first place. ORM's are a leaky abstraction on top of that, which means that when you use them you end up dealing with two problems instead of one. - SQL is superficially simple, but at scale the simplicity is a lie. Thhe performance trade-offs you make require you to understand the internals of the database you're running on and how it interprets the query, and often you feel like you're dealing with a too high level API. Often you're resigned to "tricks" to force the engine to do the right thing, like optimizer hints, special index types or denormalized data. - SQL has no ability to express relexation of the ACID principles. If you're streaming weather data into a SQL database, it could be ok to drop inserts here and there to gain throughput for the data analysis operations. SQL has no abilities to express such a thing (except in db-specific hacks).
  - Pacabel 12y ago
    Even those reasons are really stretching for it these days. There are numerous ways of dealing with hierarchical or otherwise structured data using relational DBs. Support for recursive CTEs is becoming more common, which makes such querying quite clean and simple. And with many relational systems offering support for storing and manipulating XML and JSON data, storing more structured data becomes a non-issue. I think that SQL managing to hide a lot of the underlying implementation details is one of its strongest points. In many situations the defaults are more than sufficient, saving developers and users a significant time. Yes, there are situations where more control over the exact handling is needed, but it gives ways of managing this. At least a simplified, high-level abstraction is offered; many NoSQL systems immediately force you to take a very low-level approach for even the simplest of queries. And I don't see the ability to intentionally lose data as something that's good, either. The database should be concerned with doing everything in its power to protect and ensure the integrity of the data it has been given. If it's fine to lose some of that data, then whatever or whoever is providing that data should just not provide it to the DB in the first place. So while some people may present those as possible disadvantages of SQL, I just don't think the arguments really hold up upon further scrutiny.
- kitsune_ 12y ago
  Paraphrasing Rich Hickey: It's primarily a user oriented language and there is no underlying abstraction for external programs or systems. In the end programmatic access boils down to using StringBuilders.

mamcx 12y ago

In what sense SQL is bad?

nknighthb 12y ago
I see no reason to reproduce Wikipedia's laundry list: http://en.wikipedia.org/wiki/SQL#Criticism http://en.wikipedia.org/wiki/SQL#Criticism
- jeltz 12y ago
  Wikipedia's laundry list contains of two items: * SQL not being relational algebra * SQL implementations being incompatible Both are real but I have not experienced either of these being a problem in real usage. Despite the problems caused by NULLs and that SQL allows duplicates I do not think the alternative would be better for real world programming. And the incompatibilities are avoided by picking one database per project and sticking with it.
  - nknighthb 12y ago
    Even if you reduce it to its most basic issues, you missed a third: Incompleteness of implementations. If you have not experienced problems as a result of these core issues, it honestly makes me feel you must not have a lot of experience -- at least not in diverse projects and environments. That you think picking one database is some sort of viable solution in the general case amplifies that feeling. That is so often simply not an option, and even where supporting only one database at a time is an option, you absolutely cannot guarantee that you will not have to migrate later. I've been through that pain many times, it is a real-world problem.
    - deleted 12y ago
      [deleted]
    - deleted 12y ago
      [deleted]
    - jeltz 12y ago
      I honestly think you should look at the database just like any other piece of your code, you cannot just replace GTK with WX Widgets and except there to be no migration work. And most of these differences between databases have nothing to do with SQL, but rather databases not implementing it correctly for legacy reasons. I would not expect a new database query language or NoSQL databases to do this better.
Joeri 12y ago
Well, I like SQL, but let me play devil's advocate and guess at some of the ways people may consider it "bad": - SQL queries flatten structured and hierarchical relationships into unstructured rows, often requiring very creative join operations to get at the exact set of data you want, after which you then have to convert everything back to the structured data you wanted in the first place. ORM's are a leaky abstraction on top of that, which means that when you use them you end up dealing with two problems instead of one. - SQL is superficially simple, but at scale the simplicity is a lie. Thhe performance trade-offs you make require you to understand the internals of the database you're running on and how it interprets the query, and often you feel like you're dealing with a too high level API. Often you're resigned to "tricks" to force the engine to do the right thing, like optimizer hints, special index types or denormalized data. - SQL has no ability to express relexation of the ACID principles. If you're streaming weather data into a SQL database, it could be ok to drop inserts here and there to gain throughput for the data analysis operations. SQL has no abilities to express such a thing (except in db-specific hacks).
- Pacabel 12y ago
  Even those reasons are really stretching for it these days. There are numerous ways of dealing with hierarchical or otherwise structured data using relational DBs. Support for recursive CTEs is becoming more common, which makes such querying quite clean and simple. And with many relational systems offering support for storing and manipulating XML and JSON data, storing more structured data becomes a non-issue. I think that SQL managing to hide a lot of the underlying implementation details is one of its strongest points. In many situations the defaults are more than sufficient, saving developers and users a significant time. Yes, there are situations where more control over the exact handling is needed, but it gives ways of managing this. At least a simplified, high-level abstraction is offered; many NoSQL systems immediately force you to take a very low-level approach for even the simplest of queries. And I don't see the ability to intentionally lose data as something that's good, either. The database should be concerned with doing everything in its power to protect and ensure the integrity of the data it has been given. If it's fine to lose some of that data, then whatever or whoever is providing that data should just not provide it to the DB in the first place. So while some people may present those as possible disadvantages of SQL, I just don't think the arguments really hold up upon further scrutiny.
kitsune_ 12y ago
Paraphrasing Rich Hickey: It's primarily a user oriented language and there is no underlying abstraction for external programs or systems. In the end programmatic access boils down to using StringBuilders.