Comment by ken
7 years ago
This article misses the single biggest failing of SQL, in my mind: that it's not a language. It's a family of incompatible languages, with similar syntax -- like "Lisp".
I can't write a program that works against 'any database', because switching databases means a lot of extra custom work. That means databases can't easily compete against each other. (Oracle's license terms sure don't help.) That's terrible. It's worse than x86/PPC/ARM -- at least with CPUs, a compiler can generate machine code for any of them, coming from the same source code.
Your point seems a little like tilting at windmills to me. Different databases written by different entities who didn't have a huge incentive to strictly conform to each others syntax varied in their implementations. This is just life.
> It's worse than x86/PPC/ARM
You're... saying that there should only be one CPU architecture too?
> This is just life.
Market forces naturally explain what we have today, therefore ... I'm Don Quixote. Sure, I'll accept the title. Likewise, I could say: if you don't like reading complaints like this, blog posts and internet comments might not be for you. :-)
> You're... saying that there should only be one CPU architecture too?
No. I'm saying that the analogous situation with CPU architectures was observed 50 years ago, and despite causing inefficiencies (especially at first), we've spent the effort to create abstractions to gradually make it easier to describe systems at a higher level. It generally doesn't matter, to either users or developers, that there are multiple CPU architectures. We still have many programming languages, too.
Databases have gone in the opposite direction: while adding features over the years, even when these features are 99.9% functionally identical between vendors, they've picked different syntax and data types. Even though they all speak "SQL", databases are more incompatible today than ever.
I guess what I'm getting at is: it's a good thing that compilers were invented before all software needed an ROI, and it's a shame databases didn't get the same treatment before corporate interests took over.
Exactly. The situation is even worse because many libraries support only "common ground of SQL" and therefore underutilize the real capabilities of the database.
We mentioned that there are "many SQLs" in this blog post, but not in this specific context.