Michael O’Leary CA

Meander Smith KS
Morningstar Greene TN
Reginald Blotchet-Halls OR
Innes del Castillo MI
The resulting data is sometimes called a result set, work table, or derived table,
differentiating it from the base table in the database that is the target of the SELECT
statement.
It is important to note that the relational operation of projection, not selection, is
specified using the SELECT clause (that is, the keyword SELECT followed by a list
of expressions to be retrieved) of a SELECT statement. Selection—the operation of
retrieving specific rows of data—is specified using the WHERE clause in a SELECT
statement. WHERE filters out unwanted rows of data and retrieves only the reques‐
ted rows. Continuing with the previous example, the following statement selects
authors from states other than California:
SELECT au_fname, au_lname, state
FROM authors
WHERE state <> 'CA';
Whereas the first query retrieved all authors, the result of this second query is a
much smaller set of records:
au_fname au_lname state
---------------- ----------------------------------- -------------
Meander Smith KS
Morningstar Greene TN
Reginald Blotchet-Halls OR
Innes del Castillo MI

Different vendors allow you to join varying numbers of tables

in a single query. Whereas older database platforms allowed
no more than 256 joins within a given query, today most data‐
base platforms are limited only by available system resources.
However, keep in mind that your database engine will con‐
sume more system resources and incur more latency the
more tables you join in a single query. For example, a single
SELECT statement joining 12 tables will have to consider up to
28,158,588,057,600 possible join orders.
Today’s database query optimizers are very sophisticated and
employ cost-based optimizations and heuristics to make per‐
forming queries involving a dozen or more joins a manageable
task. However, many experienced SQL developers try to limit
their SELECT statements to 16 or fewer joins in order to keep
the query’s logic easy to understand. In other situations, expe‐
rienced SQL developers might use alternative coding practi‐
ces, such as common table expressions (CTEs), temporary
tables, or subqueries, to achieve good performance.

10 | Chapter 1: SQL History and Implementations

By combining the capabilities of projection and selection in a single query, you can

SQL History
use SQL to retrieve only the columns and records that you need at any given time.
Joins are the next, and last, relational operation covered in this section. A join
relates one table to another in order to return a result set consisting of related data
from both tables.
The ANSI/ISO standard method of performing joins is to use the JOIN clause
in a SELECT statement. An older method, sometimes called a theta join, analyzes
the join search argument in the WHERE clause. The following example shows both
approaches. Each statement retrieves employee information from the employee base
table as well as job descriptions from the jobs base table. The first SELECT uses the
newer ANSI/ISO SQL JOIN clause, while the second SELECT uses a theta join:
-- ANSI/ISO style
SELECT a.au_fname, a.au_lname, t.title_id
FROM authors AS a
JOIN titleauthor AS t ON a.au_id = t.au_id
WHERE a.state <> 'CA';

-- Theta style
SELECT a.au_fname, a.au_lname, t.title_id
FROM authors AS a,
titleauthor AS t
WHERE a.au_id = t.au_id
AND a.state <> 'CA';
Although theta joins are universally supported across the various platforms and
incur no performance penalty, this is considered an inferior coding pattern because
anyone reading or maintaining the query cannot immediately discern the argu‐
ments used to define the join condition from those used as filtering conditions.

There are more issues with theta joins than ease of readability.
For example, Oracle allows only one outer join comparison
using (+), which can be quite a problem when logically con‐
structing an outer join on a multicolumn key. In a situation
like this, it can be difficult to avoid syntax errors or even
retrieving the wrong result set.

For more information about joins, see the <JOIN Subclause= on page 278.

History of the SQL Standard

In response to the proliferation of SQL dialects, ANSI published its first SQL stan‐
dard in 1986 to bring about greater conformity among vendors. This was approved
by the ISO in 1987 and followed by a second, widely adopted standard in 1989 (also
approved by the ISO). ANSI/ISO released their first joint update in 1992, known
as SQL2, SQL-92, or SQL:1992, and a second in 1999, termed SQL3, SQL-99, or
SQL:1999. The next update, made in 2003, is referred to as SQL:2003 and so on.

History of the SQL Standard | 11

 Between the release of SQL:1992 and the development of
SQL:1999, the SQL draft specifications were divided into
SQL3 and SQL4. However, the SQL4 draft was pruned, and
the SQL3 draft was adopted as SQL:1999. After this point, the
names of the SQL standards transitioned permanently to the
SQL:yyyy designation.

Each revision of the SQL standard, officially known as ISO/IEC 9075 Database
Language SQL, adds new features and incorporates new commands and capabilities
into the language. Here is a brief list of the releases and some of their major
contributions (features or specifications):
SQL-87
Standard first formalized by ANSI; support for transactions and CREATE, READ,
UPDATE, and DELETE operations

SQL-89
Minor revision, added referential integrity constraints
SQL-92
Major revision (ISO 9075), added support for internationalization, etc.
SQL:1999
Added support for user-defined types, regular expression mapping, triggers,
procedural and control-flow statements, and more
SQL:2003
Added support for XML and OLAP (window functions), sampling, and
enhanced numeric functions
SQL:2006
Clarified how SQL and SML interact and added support for XQuery
SQL:2008
Incorporated various improvements and enhancements that had been made
in several of the most prominent RDBMS platforms (INSTEAD OF triggers,
TRUNCATE statement, FETCH clause, etc.) and expanded the XML specification

SQL:2011
Introduced new features for managing temporal data
SQL:2016
Described how SQL interacts with JavaScript Object Notation (JSON) and
added support for polymorphic table functions and row pattern matching
SQL:2019
Described how SQL interacts with multidimensional arrays (MDAs)

12 | Chapter 1: SQL History and Implementations

The capabilities added in SQL:2019 and the planned SQL/PGQ (Graph Query Lan‐

SQL History
guage) extension are not yet supported in the products considered in this edition of
SQL in a Nutshell, so our coverage in this book extends only to SQL:2016. SQL:2019
coverage will come in future editions.

Levels of Conformance
SQL-92 introduced three levels of conformance indicating degrees of compliance
with the standard: Entry, Intermediate, and Full (the U.S. National Institute of
Standards and Technology later added a Transitional level between the first two).
Vendors had to achieve at least Entry-level conformance to claim ANSI/ISO SQL
compliance. Each higher level of the standard was a superset of the subordinate
level, meaning that each higher level included all the features of the lower levels of
conformance.
Later, SQL:1999 altered the base levels of conformance, doing away with the original
three categories. Instead, it required vendors to implement a minimum set of
mandatory features collectively called <Core SQL= in order to claim (and advertise)
that they are SQL:1999 compliant. This included the old Entry Level SQL-92 feature
set, features from other SQL-92 levels, and some new features. Vendors could also
opt to implement additional parts of the standard, described in the next section.

Parts of the SQL Standard

Since SQL:1999, the SQL standard has been divided into a set of parts, numbered
1 to 14 (as of SQL:2016). Not all of these were publicly released, and not all
achieved widespread adoption. The following list describes the different parts of the
standard:
Part 1, SQL/Framework
Includes common definitions and concepts used throughout the standard.
Defines the way the standard is structured and how the various parts relate
to one another, and describes the conformance requirements set out by the
standards committee.
Part 2, SQL/Foundation
Includes the Core, the central elements of the language, including both manda‐
tory and optional features. This is the largest and most important part of the
standard.
Part 3, SQL/CLI (Call-Level Interface)
Defines the call-level interface for dynamically invoking SQL statements from
external application programs. Also includes more than 60 routine specifica‐
tions to facilitate the development of truly portable shrinkwrapped software.
Part 4, SQL/PSM (Persistent Stored Modules)
Standardizes procedural language constructs similar to those found in
platform-specific SQL dialects such as PL/SQL and Transact-SQL.

History of the SQL Standard | 13

Part 9, SQL/MED (Management of External Data)
Defines the management of data located outside of the database platform using
datalinks and a wrapper interface.
Part 10, SQL/OLB (Object Language Binding)
Describes how to embed SQL statements in Java programs. It is closely related
to JDBC, but offers a few advantages. It is also very different from the tradi‐
tional host language binding possible in early versions of the standard.
Part 11, SQL/Schemata
Defines over 85 views used to describe the metadata of each database and
stored in a special schema called INFORMATION_SCHEMA.
Part 13, SQL/JRT (Java Routines and Types)
Defines a number of SQL routines and types using the Java programming
language. Several features of Java, such as Java static methods and classes, are
supported.
Part 14, SQL/XML
Adds a new type called XML, four new operators (XMLPARSE, XMLSERIALIZE,
XMLROOT, and XMLCONCAT), several new functions (described in Chapter 7), and
the new IS DOCUMENT predicate. Also includes rules for mapping SQL-related
elements (like identifiers, schemas, and objects) to XML-related elements.
There is also a Part 15, SQL/MDA, which, as mentioned earlier, first appeared in
2019 and is’nt included in the SQL:2016 standard. Note that Parts 5–8 and Part 12
were not released to the public by design. Parts 5 and 8 were originally defined
within Part 2, SQL/Foundation, then split out, but were later merged back into
the same part. Parts 7 and 12 were canceled due to lack of progress, and the
key requirement for Part 7, temporal support, was ultimately added to Part 2 in
SQL:2011.
The SQL standard, which covers retrieval, manipulation, and management of data,
formalizes many SQL behaviors and syntax structures across a variety of platforms.
This standard has become even more important as open source database products,
such as MySQL and PostgreSQL, have grown in popularity and begun being devel‐
oped by virtual teams rather than large corporations.

Be aware that an RDBMS platform may claim SQL compli‐

ance by meeting the basic Core SQL:1999 standards, so read
the vendor’s fine print for a full description of its ANSI/ISO
conformity. An understanding of the various parts of the stan‐
dard will help you get a clearer idea of the capabilities of a
particular RDBMS and of how different features might behave
when SQL code is transported to other database products.

This book details the SQL implementations of four popular RDBMSs. These ven‐
dors do not fully support everything defined in the SQL standard; all RDBMS

14 | Chapter 1: SQL History and Implementations