From storage paths to data relations

Structured Query Language, or SQL, is a language for defining and manipulating databases, not simply a single query statement as a literal reading of its name might suggest. Its development was closely linked to relational-database research at International Business Machines' San Jose Research Laboratory. In 1970, Edgar Codd proposed the relational model so that users would not need to know how data were arranged internally and applications would not repeatedly require rewriting when storage methods changed.

In this approach, information could be represented as relations with rows and columns, making retrieval a question of which data met a condition rather than which physical links to follow. The relational model supplied a theoretical direction, but accountants, engineers and application programmers also needed a readable, composable form of expression and a database system that could translate those expressions into machine operations.

References: [1] [2]

Chamberlin and Boyce's language design

Donald Chamberlin and Raymond Boyce experimented with replacing compact mathematical notation with more familiar English keywords. Their 1974 paper called the proposal SEQUEL, for Structured English Query Language. Building on the table-manipulation approach of the earlier SQUARE data sublanguage, it used nestable statement blocks so that complex questions could be assembled from simpler ones.

The paper did not aim to make machines understand unrestricted natural English. Users still had to learn fixed syntax and data structures, but did not need to write a detailed traversal procedure for every retrieval. The authors particularly considered people with business knowledge who were willing to learn a high-level language but were not computer specialists. This user-oriented choice was an important motivation for the design.

References: [2]

A department-store query

The original paper illustrated the method with department-store data. Suppose an EMP table recorded employee names in NAME and departments in DEPT. The query “SELECT NAME FROM EMP WHERE DEPT = 'TOY'” would retrieve the names of employees in the toy department. SELECT identified the column to return, FROM the table to use and WHERE the condition selecting rows. This was the paper's basic pattern, not a complete account of all later SQL syntax.

The example shows that a statement described a desired result without specifying where to start reading on disk or which index or scan order to use. Table contents, query expressions and execution methods were treated separately. This distinction was especially important for complex queries: the same data requirement could have several execution methods, leaving the choice to the system implementing the language.

References: [2] [3]

System R turns expressions into executable work

IBM's System R project was a crucial testbed. The system had to do more than recognize syntax: it also had to manage multiple users, transactions and efficient execution. Patricia Selinger and colleagues' 1979 paper specifically examined selection of access paths for SQL requests, including single-table retrieval and multi-table joins. The optimizer considered both join order and access methods for each table, comparing the costs of executing the entire statement.

Chamberlin's recollections record experimental System R installations at three IBM customer sites, with early experience feeding back into the 1976 language design. In 1977, SEQUEL was shortened to SQL because of a trademark issue. Commercial implementations subsequently emerged and the research language entered practical business settings, but prototype trials, product delivery and standards approval remained different stages.

References: [3] [4]

What 1986 actually marked

On 16 October 1986, the American National Standards Institute approved ANSI X3.135-1986, Database Language SQL. The original standard's foreword stated that technical work had been carried out by database technical committee X3H2 and concerned interfaces for defining, querying and modifying relational databases. The year 1986 was therefore an important standardization milestone, not the year in which Chamberlin and Boyce first designed or released the language.

The International Organization for Standardization subsequently published ISO 9075:1987. Its official catalogue dated the first edition to June 1987, with the lifecycle record giving 25 June as the publication date. The two records should be identified separately rather than merging US approval and international publication into one day. The standards supplied implementers and users with common syntactic and semantic references and a defined basis for discussing product compatibility.

References: [5] [6]

A common language and unresolved questions

SQL separated business questions from details of physical storage, allowing database tools, application development and staff training to develop around similar language. Chamberlin later observed that standards helped competing products share a foundation, but vendors might implement only some features or add proprietary extensions. A common name therefore did not guarantee that a program could move between systems without modification.

Practical SQL was not a provision-by-provision translation of Codd's relational model. Choices involving duplicate rows, null values and three-valued logic affected query results, and business users still had to understand the meaning of their data. Later versions continued to add and revise capabilities, forming a further history. Early SQL's central contribution was gradually connecting declarative data requirements, working database implementations and public standards.

References: [4] [5]