The use a formal, mathematical abstraction (relational algebra), even if somewhat crapily implemented by particular RDBMS, to facilitate saving data, relationships between data, and queries, while at the same time assuring certain properties (e.g. ACID) and doing so in a platform/programming language neutral format and with a consistent and industry standard query interface.
NoSQLs, key-stores and the like are not newer developments -- they predate databases. They were found to be a bad fit for what we wanted in enterprise use, and RDBS caught on.
For uses with huge data (Google and such scale) a denormalised approach might be more practical for performance reasons, in which case developers and ad-hoc programs get to re-implement all the functionality and assurances of a RDBMS in an ad-hoc way on top of rawer stores. (And all this could be alleviated with a properly optimised RDBMS for such purposes the still respects relational algebra).
In a conventional enterprise setting on the other hand, a DB trumps NoSQL etc solutions any day of the week.
>Database queries seem like a solution to the problem of storing data on disk when RAM was too expensive. So today it's still used as some sort of standard, but when you can have 16GB of ram, I think you better teach yourself what sort of algorithm and data structures a database use to be faster, use the ones you like and need and solve your problem case by case.
The whole idea is to free the data from being tied to a particular language, data structures and algorithms.
Back in 2000-2007 it was all about XML, and how we should store data in XML format and get them back with XQUERY, XPATH and the like. A lot of people bought into the hype and the resulting products. Then it was about JSON -- and we now have JSON stores. In 10 years, it will be something else, again ad-hoc.
Meanwhile SQL has worked for the past 3+ decades, and is based on a solid mathematical abstraction (relational algebra).
>It's like one of those things when a programmer had an idea which is based on a constraint, everyone starts using it, several products are made, but nobody really remember the original idea of the inventor of that paradigm.
You'd be surprised. Or rather you're exactly right -- few "really remember the original idea of the inventor of that paradigm", and that's why we're moving in circles with ad-hoc technologies re-implemented 30+ years after they were discarded. Or why people jumped enthusiastically to Mongo to return crying back to PostgreSQL.
Read a little around here for example:
http://www.dbdebunk.com/2015/07/the-sql-and-nosql-effects-wi...
http://www.allanalytics.com/author.asp?section_id=2386&doc_i...
http://www.dbdebunk.com/2015/11/moving-in-circles-sql-for-no...