There are few skills more useful in a programming career than SQL. For a language invented in 1974, that’s pretty good.

History

I originally learned SQL in university while helping write reports for a Microsoft Access 97 database. The database schema was fortunately fairly well-normalized, and reports are a great way to learn how to query.

I’d fooled around with various toy database systems before but the discovery that you could join tables together in interesting ways really opened up my imagination. Soon I was creating Access databases to track all kinds of things. Little did I know that Access work would continue well on into my career!

I picked up some consulting work while I was in university, working on Microsoft Commerce Server. This was running on SQL Server 6.5, where certain features were not yet developed. For instance, when writing a query:

the optimizer didn’t determine which order to join the tables in – it joined them in the order you specified in the query
the optimizer didn’t care about table cardinality when joining tables – it would happily join 10,000 records against 20,000 only to eliminate all but one with the next join
the optimizer pretty much required you to place tables that would be joined on separate disks (e.g. when joining A-B-C you would put A and C on one disk and B on another)

Obviously writing performant queries was very difficult.

At my first job (at a now defunct software shop) we build custom software solutions for businesses that were smaller than enterprise. Their preference was that we build databases in Access because they felt they’d have the ability to write reports more easily and create forms at-will. That was, uhhh, mostly true. One of the first things I learned when doing this kind of work was to store the data in one .MDB file and the forms, queries, and reports in another .MDB file. There was no such thing as a “migration” back then – you did that manually, or wrote VBScript to do it for you.

Only later on did Microsoft make it easier to build your Access solutions with a SQL Server (or other “proper” RDBMS) backend. Then Access really wasn’t that bad, but the web was starting to take off and nobody wanted these kinds of solutions anymore.

At my next job we were on a SQL Server backend and building COM+ components that would more often than not make SQL queries against the database. As a developer it was expected that I know the proper queries to write, how to optimize them, and when to use T-SQL stored procedures when appropriate.

Another useful thing about SQL is that data can be moved between different RDBMS’ with an already-defined interface – SQL itself! In one case we migrated data from a DB/2 database to SQL Server using Microsoft DTS (ETL), but it could have been done by exporting the data from DB/2 into CREATE TABLE and INSERT statements that are run against the SQL Server database.

After leaving the enterprise world, I found myself in the startup world (a backwards reverse transition for some), but SQL was still around (MySQL). All the skills I’d learned so far were still applicable, though triggers and stored procedures weren’t as common, probably because consumers of an OSS RDBMS are less inclined to lock themselves into it. Things like ORMs were more common, which generate their own SQL, and custom ordering of joins and selective column selection were no longer common optimization techniques.

Modern Usages

A recent trend has been to adopt SQL-like interfaces to management tools, like NRQL (New Relic Query Language) for New Relic Insights, or JQL for JIRA.

I suppose the extrapolation indicates this:

All data can be represented relationally (even if it’s not the optimal representation).
A SQL-like language can be used to query that data.
If you have learned SQL, you can understand other SQL-like languages with little effort.

More modern SQL systems have introduced timeseries abilities, which include custom language extensions to aggregate data by a timestamp. Think of how many times you’ve done a GROUP BY YEAR(date), MONTH(date), DAY(date) and imagine you could just TIMESERIES 24 HOURS like you can in NRQL.

Conclusion

Learn SQL, preferably on a proper relational database like Postgres or MySQL. This will allow you to understand most SQL-like languages.