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 bootsy on Thursday May 04 2017, @04:45PM (4 children)
Relational theory uses set theory and boolean predicate logic. This is very, very powerful especially for ad hoc queries. Try doing that in a hierachical object data store.
SQL then takes this powerful framework and cripples it. The common use of NULL forces a half implemented usage of tri-value logic that causes a lot of confusion. If the value is not applicable or simply not known yet then we should have values that tell you that state or better yet normalise so the misising information is in a second table that doesn't have a row at all.
If you've ever seen Tutorial D by Chirs Date and Hugh Darwin you begin to see what a database query language could have been. Being able to pass sets around and manipulate them using set operators easily is sadly not what SQL gives us.
On the plus side, in SQL you say what you want and not how to do it and the query engine works out the best way to do it. ( Except it often doesn't and you end up having to index and partition to improve queries but at least modern SQL Database warn when the query plan is going to be poor ).
(Score: 2) by kaszz on Thursday May 04 2017, @11:50PM
What would "Tutorial D" enable me to do that SQL would not allow?
(Score: 0) by Anonymous Coward on Friday May 05 2017, @05:06AM (2 children)
"Null" is a hotly debating topic. While it's possible to design tables without ever using it, it can create what most would consider a mess of "slim" tables.
I don't think they can practically be removed, BUT how they are handled by common operators could use a review. For example, if you concatenate 3 strings and any one of them is Null, the ENTIRE expression is null", a poison pill. Null strings should be treated as zero-length strings in concatenation in my opinion.
How they are handled in comparison operators is also suspect. For example if I have the clause: WHERE NOT x = 3, it should still return rows where x is Null in my opinion.
(Score: 0) by Anonymous Coward on Friday May 05 2017, @08:16AM (1 child)
Why do your strings allow null (Unless they were the result of an outer join)?
While having string fields allow null can make sense in some cases, every single time a colleague has wanted a string field to allow nulls, I ask them "what's the difference - in this specific field - between null and an empty string" - not once have I gotten an answer indicating that there is a valid reason to allow a string to be null.
(Score: 0) by Anonymous Coward on Sunday May 07 2017, @07:33AM
One cannot always control who puts what in the data. The data user is not necessarily the data-writing app developer. This is a common issue in bigger shops.