Stories
Slash Boxes
Comments

SoylentNews is people

posted by on Thursday May 04 2017, @11:47AM   Printer-friendly
from the fun-with-injections dept.

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!


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Friday May 05 2017, @05:06AM (2 children)

    by Anonymous Coward on Friday May 05 2017, @05:06AM (#504685)

    "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)

    by Anonymous Coward on Friday May 05 2017, @08:16AM (#504731)

    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

      by Anonymous Coward on Sunday May 07 2017, @07:33AM (#505754)

      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.