Not the SQL of My Kindergarten Days

The relational model was invented by IBM researcher Edgar Codd (1923–2003) when I was in kindergarten. Here’s a picture of my kindergarten class; one of those cute little tykes is me.

Codd made proposals for “data base sublanguages” in his paper Relational Completeness of Data Base Sublanguages (1972). As IBM researcher Donald Chamberlin recalled later: [Codd] gave a seminar and a lot of us went to listen to him. This was as I say a revelation for me because Codd had a bunch of queries that were fairly complicated queries and since I’d been studying CODASYL, I could imagine how those queries would have been represented in CODASYL by programs that were five pages long that would navigate through this labyrinth of pointers and stuff. Codd would sort of write them down as one-liners. These would be queries like, “Find the employees who earn more than their managers.” He just whacked them out and you could sort of read them, and they weren’t complicated at all, and I said, “Wow.” This was kind of a conversion experience for me, that I understood what the relational thing was about after that.  (The 1995 SQL Reunion: People, Projects, and Politics)

Donald Chamberlin and fellow IBM researcher Raymond Boyce went on to implement the first “data base sublanguage” based on Codd’s proposals and described it in a short paper titled SEQUEL: A Structured English Query Language (1974). The acronym SEQUEL was later shortened to SQL because—as recounted by Chamberlin in The 1995 SQL Reunion: People, Projects, and Politics—SEQUEL was a trademarked name; this means that the correct pronunciation of SQL is sequel not es-que-el. Codd’s paper and Chamberlin’s paper can be downloaded from the Internet; they were written using manual typewriters, and Codd’s paper even contains handwritten corrections.

The SQL of today is much more powerful than the SQL of my kindergarten days. The latest ANSI SQL standard comprises thousands of pages and the one-liners of Codd’s day have given way to hundred-liners that solve extremely complex problems. In the example that follows, we demonstrate several powerful features of SQL, including common table expressions, scalar subqueries, pivoting, recursive common table expressions, outer joins, and analytic functions. Our assignment is to create a database load profile in time series format. A typical STATSPACK report only lists a point-in-time snapshot of such a database load profile, and it would therefore be useful to review the history of each component, such as logical reads or physical reads.

Click here for the complete article from the February 2010 issue of the NoCOUG Journal.