Ridiculous? Perhaps not.
I’m aware of three major reasons have been made for SQL, or query languages in general:
- A query language allows non-technical users (like managers) to interact with persistent data themselves, bypassing engineers and their applications, without requiring technical assistance.
- It allows developers to interact with persistent data in the same way, regardless of the language in which the application is written.
- It gives developers and system operators a way of quickly “looking at the data” when things go wrong.
On closer inspection, none of these stands up much. (The fourth argument — that SQL would allow developers to ignore which product of which vendor the data is stored in — is very obviously false.)
Argument #1 was the big one in the 70′s when SQL was invented. However, non-engineers using SQL never happened and by now the argument has been conclusively disproved. Users need user-friendly applications, not SQL, to accomplish anything.
Argument #2 sounds good from the perspective of the database vendor: hey, we can say we support FORTRAN just as well as Java and Python, all with the same code. The trouble is: it does not matter to developers, because they tend to develop in one language at a time. And given the hoops one has to go through to interact with a SQL database from the average language, it’s not even true.
Argument #3 is indeed true. But using SQL is hardly the only way to accomplish this objective. A debugger is another (and nobody has ever asked for a query language for a debugger.) Another way would be to map all data objects to web URLs as we do it in InfoGrid and use the web browser as the “query language”.
So why SQL? Beats me!