SQL-92: The Day Databases Finally Started Speaking the Same Language

It’s 1992, and if you’re a database developer, you know the pain of "portability." You write a beautiful query for Oracle, then try to run it on Sybase or DB2, and everything falls apart. The 1989 SQL standard was a start, but it left too much to the imagination.

Now, SQL-92 (or SQL2) is here, and it feels like the relational world is finally growing up. It’s much more comprehensive, covering everything from data types to schema manipulation.

The Beauty of Explicit Joins

The biggest win for me is the introduction of the JOIN syntax. In the old days, we did joins in the WHERE clause, which made it far too easy to accidentally create a Cartesian product or miss a join condition.

-- The Old Way (SQL-89)
SELECT Employees.Name, Departments.DeptName
FROM Employees, Departments
WHERE Employees.DeptID = Departments.DeptID;

-- The New Way (SQL-92)
SELECT e.Name, d.DeptName
FROM Employees AS e
INNER JOIN Departments AS d ON e.DeptID = d.DeptID;

It’s not just about readability; it’s about intent. The explicit INNER JOIN, LEFT OUTER JOIN, and RIGHT OUTER JOIN make it clear exactly what data you’re looking for.

Standardized Schemas

SQL-92 also brings us the INFORMATION_SCHEMA. The idea that I can query a standard set of tables to find out what tables and columns exist in the database—regardless of whether I’m on Oracle or SQL Server—is a dream come true for tool builders.

Looking Ahead

Of course, the vendors are already "extending" the standard. I’m seeing T-SQL and PL/SQL adding their own proprietary procedural extensions. We’re still a long way from a truly write-once, run-anywhere database application.

But SQL-92 gives us a solid foundation. As data volumes grow and businesses move toward client-server architectures, having a robust, standardized language to talk to our data is no longer a luxury; it’s a necessity. Now, if we could just get everyone to agree on how to handle NULL values...