All the stuff the grandparent post mentioned. Insane 3-value boolean logic. The fact that the result-set must be in the form of a table instead of a graph of data (when the client code wants a graph). Even just moving the "select" keyword to the end of the query so query-writing tools can provide some autocomplete.
Even simple things like providing a simple syntax for walking foreign key relations instead of cumbersome Join operations. Using any ORM worth its salt, I can say customer.company, whereas in native SQL I have to say "from customer join company on customer.companyid = company.companyid".
To me, SQL is like Common LISP. A fantastic invention of a bygone era that has stood the test of time... but is stubbornly resistant to real improvement and shows too many warts of its age.
And again, as the grandparent said, the cases where the abstraction fails and you end up having to figure out how exactly it's implementing your query. Abstraction failures make a tool worse-than-useless, because it means I have to not only understand the problem the tool is trying to solve, but I have to understand the tool and the quirks of its handling of the problem.
I don't want to imply that ORMs are better (the last thing we need is another abstraction layer) or NoSQL is better (throwing the baby out with the bath-water there) just that SQL is old and has not seen the kind of improvement that other languages have seen.
> The fact that the result-set must be in the form of a table instead of a graph
Don't use a hammer to screw in a screw. There are graph databases (which support ACID, btw) out there for a reason.
> A fantastic invention of a bygone era that has stood the test of time... but is stubbornly resistant to real improvement and shows too many warts of its age.
I don't get this. It is improving and it's stood the test of time because it solves a problem and solves it well.
> And again, as the grandparent said, the cases where the abstraction fails and you end up having to figure out how exactly it's implementing your query. Abstraction failures make a tool worse-than-useless, because it means I have to not only understand the problem the tool is trying to solve, but I have to understand the tool and the quirks of its handling of the problem.
I don't quite get you. When a SQL query fails, it's not because you need to understand the database arch better. It's like when a C program fails, you don't need to understand GCC to fix it. You do however, need to understand how things are being used to pull the most performance out of it as possible, just like a regular language and a compiler.
Even simple things like providing a simple syntax for walking foreign key relations instead of cumbersome Join operations. Using any ORM worth its salt, I can say customer.company, whereas in native SQL I have to say "from customer join company on customer.companyid = company.companyid".
To me, SQL is like Common LISP. A fantastic invention of a bygone era that has stood the test of time... but is stubbornly resistant to real improvement and shows too many warts of its age.
And again, as the grandparent said, the cases where the abstraction fails and you end up having to figure out how exactly it's implementing your query. Abstraction failures make a tool worse-than-useless, because it means I have to not only understand the problem the tool is trying to solve, but I have to understand the tool and the quirks of its handling of the problem.
I don't want to imply that ORMs are better (the last thing we need is another abstraction layer) or NoSQL is better (throwing the baby out with the bath-water there) just that SQL is old and has not seen the kind of improvement that other languages have seen.