SQL is the prime building block of the modern enterprise. All those exciting applications, nifty mobile apps and massive back-end projects are, essentially, useless without the data behind them. That data may not be so important at runtime if the application is just saving logs or form information, but at the end of the day, that data has to live somewhere.

Today, wherever that data ends up, it’s highly likely it will be accessed with SQL (or at the very least a SQL offshoot, be it Oracle’s PL/SQL or Microsoft’s Transact-SQL). At their cores, even the modified versions of SQL all aim for the same goal: making data stores accessible to analysts and business people.

(Related: Microsoft to bring SQL Server to Linux)

In the beginning, Edgar F. Codd, Donald Chamberlin and Raymond F. Boyce laid out the basics for relational databases in their work at IBM between 1970 and 1974. That work would form the foundation for databases for decades to come, and included the invention of not only SQL, but also the schema model for storing and organizing data into tables.

The SQL we use today bears little resemblance to the original language, created at IBM’s San Jose Research Laboratory. Originally dubbed SEQUEL, which stood for the Structured English Query Language, it was designed as a tool to help access the data in these newfangled things IBM was playing with: relational databases.

By 1979, the original SEQUEL ideas (by then shortened to SQL due to trademark concerns) had percolated within Relational Software, the company that would become Oracle. By the end of 1979, Relational offered the first commercial implementation of SQL with its Oracle V2 database for VAX.

It would take another seven years before ANSI would standardize SQL. The SQL-87 standard would lay the foundations for modern software development and data management by ensuring that different database vendors would be able to run the same queries. This made knowledge workers vastly more valuable, as they could move from company to company and not require retraining to use a different database.