SoylentNews is people
SoylentNews
SQL and relational database management systems or RDBMS were invented simultaneously by Edgar F. Codd in the early 1970s. The simple fact that both arrived early in the life of computing, and that for 90% of the time they just work, means databases have become a 'solved problem' you no longer need to think about.
It's like how MailChimp has become synonymous with sending email newsletters. If you want to work with data you use RDBMS and SQL. In fact, there usually needs to be a good reason not to use them. Just like there needs to be a good reason not to use MailChimp for sending emails, or Stripe for taking card payments.
But people do use other other email automation software and payment solutions, just like people use NoSQL databases. Yet even with other database technology available, albeit less mature technology, SQL still reigns and reigns well.
So, finally, here are 8 reasons we still use SQL 43 years after it was first cooked up.
It's clickbait, I tell ya!
(Score: 3, Interesting) by theluggage on Thursday May 04 2017, @01:01PM (18 children)
(1) Why RDBMS and (2) Why SQL
(1) is easy - its a good model of data organisation with a strong theoretical underpinning and can easily be used to implement flat files, document stores, graph databases etc. especially with a dash of "sugar" from the RDBMS (e.g. PostgreSQL's support for JSON). Obviously there's a role for specialised databases for extreme applications (e.g. graph - I'm not sure what Mongo etc. are meant to be for) but most real-world applications will benefit from the relational capabilities (e.g. you've done your document store = table with ID and a JSON field - now it needs an ownership and permissions system, which is a natural application for relational).
(2) is harder to see - SQL itself is a semantic train wreck and - even if you're a pragmatic type (or even a pragmatic tuple) and its non-mathematically-sound terminology doesn't give you hives, it's just plain inconsistent, verbose, poorly standardised and is a prime example of COBOL-esque "Unlight Lamp" syndrome. Why hasn't something more concise, logical and which makes it easier to compose queries programatticaly emerged?
(Score: 3, Insightful) by pTamok on Thursday May 04 2017, @01:29PM
I think the reason SQL continues to be used is inertia. Once the installed base is large enough, replacing the 'ecosystem' is hard.
In other words, the expected pain of transition is not outweighed by the expected gain of using something new (and hopefully better). There doesn't appear to be anything 'obviously' better.
There's also plenty of COBOL running on inertia too. Also, don't underestimate the amount of hard-coded business analysis that has gone into legacy applications. If you just re-code the codebase in a new language, you find you have swapped one fragile set of inter-related processes implemented on a computer for an equivalent set of of fragile inter-related processes on a computer, with no actual gain in business agility. Doing the job properly, by doing a proper analysis of the current business and its goals, then writing the support software in the light of that analysis, then managing the transition from old to new, is costly and takes time. You need some pretty amazing benefits to justify it.
(Score: 2) by goodie on Thursday May 04 2017, @02:44PM
Why hasn't something more concise, logical and which makes it easier to compose queries programatticaly emerged?
My personal opinion is that it's because it's really hard to actually do that well. As in 90% will be relatively easy and the last 10 will be a big mess (see my other post on the Vietnam reference). The big PITA is also vendor-specific implementations of SQL, support or lack thereof for certain features etc. That makes it difficult to work with multiple RDBMS without some sort of translation tool that will not have everything implemented for every platforms etc. And data type conversion between the RDBMS and the application can also be tough sometimes...
(Score: 2) by Grishnakh on Thursday May 04 2017, @04:21PM (5 children)
and is a prime example of COBOL-esque "Unlight Lamp" syndrome
How is this a bad thing? "Unlight lamp" reminds me of the text adventures of the early 80s, back when computers actually used to be fun. Now with Windows 10, spyware, ridiculously slow software despite incredibly powerful hardware, and worst of all, flat UIs, computers just aren't much fun any more.
I remember the days when computers run at under 1 MHz (sometimes well under), yet they could accept keypresses as fast as you could type them. These days, there's a huge, visible lag in typing most of the time, despite CPUs being over 1 or 2 GHz and having tons of extra helper hardware (GPUs, DMA, etc.). Software has gotten so ridiculously bloated that all the performance gains are squandered. Just look at the popular new way of developing desktop apps these days: Electron. "Yeah, let's spin up a whole new web browser for every simple little app!"
(Score: 3, Insightful) by theluggage on Thursday May 04 2017, @05:22PM (4 children)
How is this a bad thing? "Unlight lamp" reminds me of the text adventures of the early 80s, back when computers actually used to be fun.
Sure - its all fun and games until someone gets eaten by a grue. Or you query flies out of the server, collides with the pile of junk mail (haha!) only to be grabbed by a small lower-half-of-the-room cleaning robot*. No, I don't want to have that sort of "fun" when I'm trying to write a query - the underlying logic provides an adequate sufficiency of mental exercise.
"Natural language" computer languages like SQL, COBOL, VAX/VMS command line invariably fail because they don't really understand natural language and you end up having to memorise the correct commands anyway. Worse, they accept a small number of variations (e.g. glue words like WITH, TO that don't follow any sort of consistent logic about when they're needed) which I find makes it harder to remember.
I remember the days when computers run at under 1 MHz (sometimes well under)
Bet you could remember the hex codes for all the commonly used machine code instructions, too... So much for natural language.
These days, there's a huge, visible lag in typing most of the time,
Pro tip: Office 2016 actually does that deliberately... I threw up in my mouth a little bit. There's a registry hack to turn it off.
Electron. "Yeah, let's spin up a whole new web browser for every simple little app!"
To be fair, that's mainly Because Security: they could all run in a single browser instance if you didn't mind giving Javascript full access to your system...
*Sorry, I know I haven't got that quite right but I've got a headache and forgot to TAKE ASPRIN. (or was that TAKE ASPRIN USING GLASS... or TAKE ASPRIN USING WATER...?)
(Score: 2) by Grishnakh on Thursday May 04 2017, @05:53PM (2 children)
Bet you could remember the hex codes for all the commonly used machine code instructions, too... So much for natural language.
No, actually I'm just thinking of the 8-bit microcomputers of the time, plus also the IBM PC, various mainframes, etc. All those things were fast. Maybe not so much at actual computation speed, but they had very low latency for user-interactive stuff usually.
Pro tip: Office 2016 actually does that deliberately... I threw up in my mouth a little bit. There's a registry hack to turn it off.
WTF? Why would they do this?
(Score: 2, Informative) by Anonymous Coward on Thursday May 04 2017, @06:19PM (1 child)
Because they thought it looked good. However, you can turn it off:
http://www.laptopmag.com/articles/office-2013-typing-animation-disable [laptopmag.com]
(Score: 0) by Anonymous Coward on Friday May 05 2017, @07:39AM
Strange. My Office 2016 doesn't seem to do that, and I don't have that key. I do however have DisableHardwareAcceleration = 1, so that may be the reason.
(Score: 2) by kaszz on Thursday May 04 2017, @11:32PM
To be fair, that's mainly Because Security: they could all run in a single browser instance if you didn't mind giving Javascript full access to your system...
What is needed is a sandboxed process space. Not necessarily a full browser and all of it is still highly inefficiently designed and programmed.
On top of that. Javascript is a design error all the way.
(Score: 2) by Thexalon on Thursday May 04 2017, @04:31PM
My guess is that the problem is that the semantics can get really hard.
Here's an example of the kinds of things you need to be able to ask an RDBMS: "Given a detailed listing of each individual purchase, which includes 4 kinds of information (loyalty card number, credit card number, delivery address, and name) that may connect multiple purchases by the same customer together, how many customers in the last 6 months have purchased at least 5 pairs of shoes and 10 pairs of socks, and how much did they pay for them?"
A reasonably skilled SQL jockey should be able to put something together that would express this question correctly, and it wouldn't be all that long either compared to the description of the question I just asked in English.
It's also not like there haven't been attempts to replace SQL over the last 4 decades. Many ORMs effectively try to do exactly that by adding a code layer that translates into SQL. So far, the results have been not good enough to dislodge SQL. Which is a pretty strong indication that SQL is pretty darn good at what it does.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2, Informative) by Anonymous Coward on Thursday May 04 2017, @09:45PM
Alternative? The folks at C2 drafted up a query language tentatively called "SMEQL" that is more functional in nature, where any new operations are new functions (or API-like calls) instead of the COBOL-esque key-words used by SQL.
SMEQL Overview [c2.com]
Base operators [c2.com]
Example query [rosettacode.org]
Column selection can be "meta-tized" in that you can use the regular table operations to "compute" which columns to show (SELECT equivalent). This can allow one to use a data-dictionary (column description table(s)) to select columns.
Spread the word.
Another possible contender is Tutorial-D and its close cousin "REL", but it also suffers some syntactic complexity problems. The REL implementers are allegedly more concerned with "relational purity" than syntax simplification. The purity issue is not a show-stopper with SMEQL, and "solving" it would only have a minor impact on the draft SMEQL standard. (The "purity wars" get nasty.)
(Score: 3, Funny) by requerdanos on Thursday May 04 2017, @10:12PM
SQL itself is a semantic train wreck... Why hasn't something more concise, logical and which makes it easier to compose queries programatticaly emerged?
Well, Soylentnews has a story on their front page giving eight reasons why. Here's a link to the story itself [sqlizer.io] and to the SN coverage [soylentnews.org]. If you're in a hurry just expand the spoiler for a quick list of all eight reasons.
(Score: 2) by meustrus on Friday May 05 2017, @02:47AM (6 children)
SQL has its problems, to be sure. But in its defense, it is one of the only languages we use that describes what the result looks like instead of . The beauty in SQL is that most of the time the database engine can figure out the most efficient algorithm to fetch your data just based on your spec. You just can't do that with procedural or object-oriented code.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 2) by Wootery on Friday May 05 2017, @04:05PM (4 children)
Well, obviously. That's not a defence of SQL, it's a defence of relational database languages. The question is whether SQL is good at what it does.
SQL has lots of silly things like using a different syntax for UPDATE vs INSERT, for instance. If we could burn it down and start over, we could fix those.
(Score: 0) by Anonymous Coward on Sunday May 07 2017, @07:38AM (1 child)
While I agree there's a lot of annoyances with the syntax, that particular thing can be fixed in a new standard version by allowing both "styles" with either command. Thus, that specific problem is not a reason to start over.
(Score: 2) by Wootery on Tuesday May 09 2017, @03:57PM
In reality what's happened is that MySQL invented a non-standard INSERT syntax with the UPDATE-like named-parameters style, and it won't work outside MySQL. [bennadel.com]
I agree MySQL isn't so terrible that we should start again, but it sure ain't perfect.
(Score: 2) by meustrus on Tuesday May 09 2017, @01:43PM (1 child)
Other such languages being...? I'd love to see another language that specifies the result instead of the algorithm. Your UPDATE vs INSERT example is just one of the many problems I alluded to, but without an alternative I think it's just something we put up with.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 2) by Wootery on Tuesday May 09 2017, @03:53PM
Yes, exactly my point. It's not a particularly great language, it's an acceptable language of a very useful kind.
(Score: 2) by meustrus on Tuesday May 09 2017, @01:40PM
Huh, I really should have previewed that first. A broken tag got rid of the end of sentence two ("how to get the result") and borked the rest of the comment.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?