5 ms·

> SQL seems like a terrible language. The reason you give is too trivial to justify calling it "a terrible language"

by return0 10y ago

d33 10y ago
Okay, so another reasons are: that 1) it's terribly difficult to parse and 2) on large tables, messing with query planner is actually more work than just specifying the algorithm you'd like to use. Also: 3) yes, there is an SQL standard, but generally if you're writing any application that uses SQL, you're going to end up writing code for a specific database or use an ORM.
JustUhThought 10y ago
E.F. Codd (author of the whitepaper that is the foundation of all RDBMSs, for which SQL was created to query) was of the opinion that the SQL was a terrible language. His reasoning for saying so are very clearly and well speelled out in several books and articles of his.
mamcx 10y ago
That reason is in fact a good one. The order is "wrong" from the point of view of a developer and maybe ok from the POV of the original intent of SQL: The end-user was supposed to run SQL against databases. Few ad-hoc queries, even complicated, can be managed. But using SQL all the time, and the language is clearly the wrong thing to talk to the DB (is like JS: Is what you have instead of what you want). Also: The fact that everyone run (even if eventually fail) for a ORM instead of SQL, or the way people imagine NOSQL is "better" -is very telling is NO SQL- show this. The relational model is so simple and powerfull, but SQL is not a good seller of the idea.
- bluejekyll 10y ago
  Is there another language agnostic option? I suppose it would be interesting if you could use something like the llvm to target a DB's core features, but through your language of choice. I haven't seen anything like that, if it exists. SQL is that standard API today, and ORMs provide the language specific implementation (though sometimes in ways that make it inobvious what the generated SQL will look like).
  - pjungwir 10y ago
    I actually like SQL, but I'm glad people are willing to ask, "Can we do better?" I think for a working programmer, SQL is the only practical choice, but Tutorial D is an interesting attempt to improve (by C.J. Date, described at length in his books Database in Depth and The Third Manifesto), with an open source implementation called Rel. There is also a commercial database called Dataphor that uses D4, a cousin to Tutorial D. There is also a newer project called Andl that is another non-SQL relational query language. Personally, although I'm not a researcher, I've become intrigued by ways we model change-over-time in relational databases. Snodgrass's book _Developing Time-Oriented Database Applications in SQL_ is a good entry point to all that, and more recently we have SQL2011's Temporal standard. I still have a lot to read here myself, but I am keen to see what happens in the next ten years in how the relational model can incorporate change.
    - smt88 10y ago
      SQL is a lot like JavaScript: a lot of people hate working with it, but it's the only practical choice, as you say. It's interesting to note that transpiling to SQL is even more popular than the recent trend of transpiling to JavaScript. Every major language has a query builder (many of which end up with syntax similar to Andl). We're abstracting away from SQL and have been for a long time. With that in mind, I wonder whether we need a new query language so desperately. SQL is so highly optimized in the major RDBMS that any new language would probably compile internally to SQL, meaning it has the same semantics (and is essentially sugar) OR it would be way behind SQL in terms of optimization. Am I just totally off base here?
      - pjungwir 10y ago
        After I wrote that comment I thought it might be worth submitting this Andl story to HN about Andl-on-Postgres: [0]. They write, "Relational expressions are converted into equivalent SQL and passed back to the Postgres SPI interface for execution," so you are right about transpiling. But the software world is more mature than it was 20 years ago, so it seems reasonable for a project to get a toehold by building on top of existing systems. That needn't limit its future growth necessarily. It sounds like Andl will work on more than just Postgres, so I can imagine them eventually building a "native" version too. Using existing RDBMSes is a pretty good way to get an MVP though. :-) [0] https://news.ycombinator.com/item?id=11802917 https://news.ycombinator.com/item?id=11802917
- return0 10y ago
  I think people use an ORM so that they can "switch data stores". Personally i never used one since SQL is very easy to write and its actually a Standard. Even when i did switch databases, having a standard guarantees there will be fewer changes needed, than if switching orms. Also, what people "imagine" is of zero concern.
  - mamcx 10y ago
    In theory maybe. I think instead is looking for a nicer interface (BTW: I learn new languages building a ORM!).

> SQL seems like a terrible language. The reason you give is too trivial to justify calling it "a terrible language"

by return0 10y ago

> SQL seems like a terrible language. The reason you give is too trivial to justify calling it "a terrible language"

d33 10y ago

Okay, so another reasons are: that 1) it's terribly difficult to parse and 2) on large tables, messing with query planner is actually more work than just specifying the algorithm you'd like to use. Also: 3) yes, there is an SQL standard, but generally if you're writing any application that uses SQL, you're going to end up writing code for a specific database or use an ORM.

JustUhThought 10y ago

E.F. Codd (author of the whitepaper that is the foundation of all RDBMSs, for which SQL was created to query) was of the opinion that the SQL was a terrible language. His reasoning for saying so are very clearly and well speelled out in several books and articles of his.

mamcx 10y ago

That reason is in fact a good one. The order is "wrong" from the point of view of a developer and maybe ok from the POV of the original intent of SQL: The end-user was supposed to run SQL against databases. Few ad-hoc queries, even complicated, can be managed. But using SQL all the time, and the language is clearly the wrong thing to talk to the DB (is like JS: Is what you have instead of what you want). Also: The fact that everyone run (even if eventually fail) for a ORM instead of SQL, or the way people imagine NOSQL is "better" -is very telling is NO SQL- show this. The relational model is so simple and powerfull, but SQL is not a good seller of the idea.

bluejekyll 10y ago
Is there another language agnostic option? I suppose it would be interesting if you could use something like the llvm to target a DB's core features, but through your language of choice. I haven't seen anything like that, if it exists. SQL is that standard API today, and ORMs provide the language specific implementation (though sometimes in ways that make it inobvious what the generated SQL will look like).
- pjungwir 10y ago
  I actually like SQL, but I'm glad people are willing to ask, "Can we do better?" I think for a working programmer, SQL is the only practical choice, but Tutorial D is an interesting attempt to improve (by C.J. Date, described at length in his books Database in Depth and The Third Manifesto), with an open source implementation called Rel. There is also a commercial database called Dataphor that uses D4, a cousin to Tutorial D. There is also a newer project called Andl that is another non-SQL relational query language. Personally, although I'm not a researcher, I've become intrigued by ways we model change-over-time in relational databases. Snodgrass's book _Developing Time-Oriented Database Applications in SQL_ is a good entry point to all that, and more recently we have SQL2011's Temporal standard. I still have a lot to read here myself, but I am keen to see what happens in the next ten years in how the relational model can incorporate change.
  - smt88 10y ago
    SQL is a lot like JavaScript: a lot of people hate working with it, but it's the only practical choice, as you say. It's interesting to note that transpiling to SQL is even more popular than the recent trend of transpiling to JavaScript. Every major language has a query builder (many of which end up with syntax similar to Andl). We're abstracting away from SQL and have been for a long time. With that in mind, I wonder whether we need a new query language so desperately. SQL is so highly optimized in the major RDBMS that any new language would probably compile internally to SQL, meaning it has the same semantics (and is essentially sugar) OR it would be way behind SQL in terms of optimization. Am I just totally off base here?
    - pjungwir 10y ago
      After I wrote that comment I thought it might be worth submitting this Andl story to HN about Andl-on-Postgres: [0]. They write, "Relational expressions are converted into equivalent SQL and passed back to the Postgres SPI interface for execution," so you are right about transpiling. But the software world is more mature than it was 20 years ago, so it seems reasonable for a project to get a toehold by building on top of existing systems. That needn't limit its future growth necessarily. It sounds like Andl will work on more than just Postgres, so I can imagine them eventually building a "native" version too. Using existing RDBMSes is a pretty good way to get an MVP though. :-) [0] https://news.ycombinator.com/item?id=11802917 https://news.ycombinator.com/item?id=11802917
return0 10y ago
I think people use an ORM so that they can "switch data stores". Personally i never used one since SQL is very easy to write and its actually a Standard. Even when i did switch databases, having a standard guarantees there will be fewer changes needed, than if switching orms. Also, what people "imagine" is of zero concern.
- mamcx 10y ago
  In theory maybe. I think instead is looking for a nicer interface (BTW: I learn new languages building a ORM!).