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: 4, Interesting) by goodie on Thursday May 04 2017, @01:36PM (3 children)
Haha I know, people still have a hard time (mind you they might have a hard time writing code to begin with), and I should know because I teach it to graduate students who like to write spaghetti. I see two main issues from my SQL teaching experience:
1- Many students/people who write SQL are not trained to *think* about a problem, design an algorithm, and implement/debug it. They go head first into code and it quickly becomes this mess (I always think of Tetsuo at the end of the Akira movie...) that they cannot debug. So a big part of my job is to teach them that. Think about the business issue, what you could do to solve it, and then think about code, not the other way around. Same goes for data modelling (when to/not to normalize, dimensional vs relational models etc.). Most people don't think in terms of structures, they think in terms of result. Since many engines don't provide built-in standard/pattern checking and refactoring capabilities, people get away with crap which is then bound to object models and so on (which are much nicer looking when you look at the code...).
2- For many people, thinking in sets is not very natural because they are used to thinking in a more procedural manner. So when they want to do something in SQL, they may go for cursors, while loops etc. rather than say a recursive query that can do this much more elegantly and more important, more efficiently for the engine. Typical example I use for students is a calendar table, something that is easy and can be implemented in a number of ways but for which a recursive query can be much better.
The funny thing is that with all those new things, hadoop, spark etc. the first thing that people do is slap an SQL-like interface to interact with the data (Hive, etc.). I have nothing against this but I find it amusing that every time somebody tells me that SQL is dead or some stupid comment like this, I can refer to those new things and tell them to shut up. It's still relevant. It does not mean that it's properly used but it is still relevant (for what it's worth, Stackoverflow's developer survey has included SQL as one of the top languages for a number of years).
Personally, I really like SQL. My experience with ORMs has been relatively mixed. I find that it has shifted some of the burden on the programming side but it hides some of the inefficiencies that the engine makes and can force a certain data model on the software side to obtain query patterns over others. It's aptly been referred to as the Vietnam of computer science, to me it's tough to write something that works for everybody like hibernate etc. ;-) http://blogs.tedneward.com/post/the-vietnam-of-computer-science/ [tedneward.com]
(Score: 3, Interesting) by DannyB on Thursday May 04 2017, @02:50PM
Item number 2, thinking in sets instead of procedural thinking hit the nail right on the head. That is exactly my own personal experience years ago. I could write simple queries. Then as the need for more complex queries arose, my thinking naturally tended towards how to solve the problem with loops and procedural code. I did not want to become too deeply tied to Microsoft SQL dialect, so I resisted that. Another idea was to query individual tables with the appropriate ordering, and then put it all together with procedural logic in the application server. But that seemed rather ugly to me so I didn't do it.
I thought more and more about how to solve each problem. Each problem was a new puzzle to solve. But I recognized patterns that I was using. Sub queries to generate single columns in the output. Sub queries that get a table name and are JOINed to the main tables. UNIONed queries. Generating preliminary results into temp tables scopped to the current overall query, and then using those results in subsequent queries that formed the final result.
In every case, I ended up with pages of neatly formatted code that accepted parameters and produced a single resulting table for the application server. I could make the application server spit out this entire query to the server, or I could store it in a stored procedure.
It basically dawned on me how to think in sets and joins and exclusions and inclusions. Filtering things out. Filtering things in. How to write WHERE clauses so the database could take advantages of indexes.
Once I had the Ah Ha! moment, it all seemed so simple going forward.
I don't consider myself a SQL advocate. But I recognize that it is suitable for so many problems. It's not the only tool. And not always the right tool. But it really is appropriate for many problems, especially business problems.
I've looked at recursive queries. But I have never needed one yet.
As for performance, I can throw a several page long SQL query at the server (not a stored procedure) and in 10 milliseconds get back a firehose of rows from tables with tens of thousands of rows. Reports are extremely fast. Even reports that go to hundreds of pages. The query takes a few seconds. Putting the results together through the report engine (JasperReports) into nice formatted pages take many times (still seconds) that of the query. The report filters, which ultimately affect WHERE clauses are on columns of many different tables.
The lower I set my standards the more accomplishments I have.
(Score: 3, Funny) by DeathMonkey on Thursday May 04 2017, @05:36PM
All I can say to that is;
3: TETSUOOOOOOO!!!!!!!
(Score: 0) by Anonymous Coward on Thursday May 04 2017, @10:13PM
Before SQL hit big, I used procedural query languages (or at least semi-procedural) and it was hard switching to SQL for non-trivial queries. With the procedural way, you had to manually decide what index to use or make a new temp index if that's a better option. But this also gave you a sense of the performance. When you let the RDBMS optimizer pick the query strategy and indexes, it's hard to know what it's going to do ahead of time. It mattered even more in the early days of RDBMS when the optimizers were not very good.
And, I still encounter a fair amount of problems that would be simple and quick to implement in procedural query languages such that the SQL is say 5x or more code. Maybe if I knew SQL or the dialect well enough I could simplify it, but I don't. My procedural app coding skills can transfer to procedural query languages, but NOT to SQL very well (and functional-ish (FP) languages).
Thus, the FP/set nature of SQL is not necessarily "bad" per se, but it doesn't leverage one's typical procedural skills, making some things difficult for non-specializing query writers. I have to confess that I often miss some pre-SQL query languages.