On Feb 10, 2022, at 17:06 , Mladen Gogala <gogala.mladen@xxxxxxxxx> wrote:
I feel like anyone who is defending SQL here isn’t aware of how much better the alternatives are, and how bad SQL really is.
But SQL is a terrible, no good, very bad language.
I cannot accept such a religious persecution of SQL without a detailed explanation.
I mean: it’s hard to write, hard to read. It’s hard to generate. But that’s just the starting point.
OK. If there are better alternatives, I am sure you will be able
to sell them to the world. Establish a company and have a go at
it.
One of the worst things about it that I don’t see much discussed is that it imposes assumptions about the storage model that aren’t part of the relational model. Like heavyweight, hard to change tables with transactional guarantees and such. Don’t get me wrong, those things are great to have available, but I don’t need them all the time.
Storage model and implementation are not part of SQL for good
reason. Database vendors have different implementations. MySQL and
Postgres are different. MySQL storage engines differ among
themselves. Both of them are different from SQL Server which is in
turn different from Oracle and DB2. Storage model determines the
implementation. When there is only a single relational database
vendor left in the market, then they can burn their storage
implementation into the language standard. Until then, the more,
the merrier.
The whole NoSQL movement has been such a tragedy. Having diagnosed a problem with SQL databases, they threw out the relational model and very often reimplemented a form of SQL when they should have done the opposite. There is no reason you can’t have a relational database with an on-demand schema, with eventual consistency, with all those fun things that various NoSQL databases provide. Those storage models have their place, but the SQL standard says you can’t use them.
But the biggest issue is the verbose, terrible, very bad query language. In the web development community where I spend my time, it is almost holy writ to treat the database as a dumb data bucket, and do everything in the application layer (even things like validations, even when that is a provably incorrect approach). Why? I think it’s because they’re used to working in a pleasant language like Ruby or Python, and they want to do everything there. And who can blame them?
As a database architect who has successfully bridged two very
different database systems, I can tell you that the application
programmers put the business logic into the application because
they frequently don't know what the options are. They know Java or
Python and that's what they do, period. That has nothing to do
with SQL.
Business community which hires them to make efficient applications can blame them. And frequently does so.
But this is bad. Proper relational design can take over much (most!) of the design of a typical business app, with significant efficiency gains the result. But no *community* is going to choose that when most of the members of the community don’t want to learn SQL and who can blame them?
Another issue: everyone thinks “relational” is the same thing as “SQL”. If we could get folks to break that association, then relations should be a standard feature of high-level programming languages, just as arrays and hashes are.
Heck, give me a functional programming language with a good relational model, and I can implement OOP in that relational language without breaking a sweat.
Software *should* be designed around a logical/relational layer with minimal occasional forays into Turing completeness where necessary. But no-one is even thinking about software like that because relational is SQL and SQL is awful.
-- Mladen Gogala Database Consultant Tel: (347) 321-1217 https://dbwhisperer.wordpress.com
