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: 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?