About two weeks ago at work we discussed different strategies on testing databases. Although there are ways to do it, they are all more or less painful. And finally we all parted in agreeing: (SQL) databases suck, SQL sucks and testing databases and SQL sucks as well. We are only testing this crap because the only thing worse then database tests are untested databases. But complaining doesn’t help. I have heard you are supposed to ask 5 times “why?” when faced with a problem. Maybe it was 7 times? Don’t know lets start with asking it once: Why does SQL suck?Hard to parse for computers: I don’t know much about parsing, but it seems to be hard for a computer to identify the bits and pieces of a SQL statement, when it is not really SQL but just almost SQL. This results in really crappy IDE support, because the editor doesn’t know what you are trying to write, before you finished it. Hard to parse for humans: One of the ideas behind the design of SQL was to make it look almost like a sentence. While this works for trivial statements, it completely falls a part when you have some serious statement at hand. For an extremely bad example check out the turing engine implemented in Oracle SQL. Side Note: aren’t some fluent APIs trying to do just that. Not consistent:Why does the having clause exist? Why nothing similar for group by? Who came up with the syntax of analytic functions. Why can I reference an expression defined the column list in the where clause, but not in the group by clause? (Almost) no modularization: You need this real complex where condition in another select? Copy it. You need to join the same bunch of table, just with a tiny change in one condition? Copy it. You want to use the same group by clause in a different select? Copy it. There are few little things you can do to break your SQL code, but it is nothing compared to the power of a modern language like … e.g. … Fortran 66.
Read more: Schauderhaft
Read more: Schauderhaft