Like any technology that strives to be interoperable among different implementations, SQL has been standardized. The first SQL standard was adopted and published by the American National Standards Institute (ANSI) in 1986. The standard was further ratified by the International Organization for Standardization (ISO) in 1987, and ISO continues to be the primary international standardization body for SQL.
SQL Standardization
The most recent standardization of SQL is SQL:2006, though SQL:2006 is ultimately concerned with the relationship between SQL and XML and not the further development of SQL itself.
When considering SQL syntax and functionality today, the SQL-92 and SQL:1999 standards are typically used, as they were the last major updates to SQL that were concerned with bettering the language, rather than extending it into arguably unnecessary territory.
SQL:2003 also contains some less well-known but still important parts of SQL, including window functions and standardized sequences, along with some initial XML-related features. Notably, SQL:2003 also removed the BIT and BIT VARYING data types, which were overwhelmingly poorly implemented and underused.
The ANSI SQL standard was published in 1986 as SQL-86 but was not ratified by ISO until 1987; as such, it is sometimes called SQL-87. Minor revisions were made to that original standard in 1989, under the document name SQL-89.
A relatively complete revision of every part of the SQL standard is expected some time in 2007.
Prominent revisions of the SQL standard are summarized in Table 1.
Year | Name | Comments |
1986 | SQL-86 | First SQL standard (ratified in 1987) |
1989 | SQL-89 | Minor revision |
1992 | SQL-92 | Major revision (also called FIPS 127-2) |
1999 | SQL:1999 | Minor revision |
2003 | SQL:2003 | Introduced window functions- standardized sequences- and XML-related features |
2006 | SQL:2006 | Extended SQL-XML integration |
Table 1. Revisions of SQL standards
{qbapagebreak title=Obtaining SQL Standards}
Obtaining SQL Standards
While it would make sense to have public standards available for free, ANSI and ISO both charge money to obtain SQL and other standards. Nonetheless, if one is curious about the actual wording of the standards, they can be found and purchased at the http://www.ansi.org/ and http://www.iso.org/ web sites.
SQL Pronunciation
The 1986 ANSI SQL standard declared the official pronunciation of SQL to be “es queue el”. Despite this, many people, especially those who are not technically savvy, pronounce SQL like the word “sequel”.
This has been the subject of much discussion in the SQL and database communities, and despite the “sequel” pronunciation being an irritant to passionate database technologists, that incorrect pronunciation has remained in common use.
As an aside, it is interesting to note that the official IBM System R acronym for what we now call SQL was once SEQUEL (pronounced “sequel”), which was a shortened version of Structured English Query Language.
However, the acronym was changed to SQL, simultaneously removing the word “English” from the acronym, because SEQUEL was a trademark of the Hawker Siddeley, an aircraft manufacturer.
SQL Portability
SQL database platforms tend to implement the SQL standard in different ways. For example, the SQL date and time data types are sometimes omitted in favor of proprietary solutions.
PostgreSQL notoriously contains a number of custom data types; for instance, it provides an entire range of data types that define geometric objects (e.g. box and line). These geometric object types are not necessarily available in other database systems, so the database developer who uses those types may be “locked in” to PostgreSQL.This situation would arise if converting the geometric object types to another type usable by a different database would consume too much time or be altogether impossible.
An argument typically made against complaints about SQL’s lack of portability is that the SQL standard, despite being long and complex, is not completely defined and, in some cases, is ambiguous.
Thus, the developer of the database system is left to decide how to implement certain features, like indexes and custom data types. These non-standardized implementations of features are often incompatible with other SQL database systems and lead to the lack of portability.