Revenge of the SQL (revisited)

The mainstream is always under attack. So is SQL and in general the various RDBMSs that implement their various incarnations. After the golden age of MySQL and the LAMP (Linux-Apache-MySQL-PHP) stack, various NoSQL databases appeared, preaching that the data storage as we knew it was coming to an end.

The Crusade

Everyone thought back then, that the web applications could not benefit from data with strongly enforced relations and the query language for these systems; SQL was complex and introduced overhead in terms of performance and security with the infamous SQL-injection attacks.

In addition, every programmer I know (even me) was tempted to join the crusade against the RDBMS and the SQL. At first, the problem was solved with ORMs, which mapped the database entities to specific programming language abstraction elements, such as classes. After that, millions of lines of code were written for support tools, and IDEs, all of course in the name of the crusade.

The Elusive Holy Grail

Even with all this effort and resources, the problem was in fact recursive. SQL is a Domain-Specific Language (DSL), which in plain English means that it focused on a specific problem domain. General-Purpose Languages (GPL) like Java, C++ and Python, could never offer the richness of any DSL, focused to expressed queries on data entities. Since ORMs offered abstractions on the GPLs, other query languages were designed to offer querying capabilities on the mapped objects. Programmers got rid of the SQL and the interaction with the RDBMS, but instead they had to learn new exotic variations of query languages, which in the end suffered from the same set of problems.

The NoSQL approaches were successful, but their usage is misjudged. NoSQL databases are perfect to solve specific types of problems, but they are not here to replace RDBMS systems.

The Empire Strikes Back

It seemed that the big players who provide infrastructure (IaaS/PaaS) noticed that RDBMSs are an irreplaceable piece of technology; thus they start offering turn-key solutions on their platforms, like Heroku Postgres service and Google Cloud SQL.

On the language front, it seems that the problem was not the SQL, but the way the programmers interacted with it. Next generation languages like Scala and Java 8, offer libraries like Anorm, Slick and JOOQ that offer enhancements on the interaction between these languages and SQL, providing compile-time error detection in queries and out-of-the-box optimisations.

Nowadays, even NoSQL databases like MongoDB have support for an SQL variant. SQL managed to detached itself from traditional RDBMS and became a modern query language. It is like a generalized DSL (Domain-specific Language), right?