Datasheet

Part I SQL Basic Concepts and Principles
XML is discussed in Chapter 15, ‘‘XML and SQL.’’
XML first became a part of SQL standards in 2003. SQL:2003 contains a separate document
(Part 14: ‘‘XML-Related Specifications’’) describing XML standards for SQL. The document was
superseded by a major revision in 2006 (mostly for XQuery support), and another revision is
pending and is expected to be released sometime in 2008.
Every major RDBMS release has either a new version of its product or an add-in
to the existing one to handle XML, to comply with SQL:2003 standards to a certain
degree.
While it is impossible to predict what model will emerge as a winner in the future, it seems rea-
sonable to assume that relational databases are here for the long haul and have not yet reached
their full potential. SQL as the language of the RDBMS will keep its importance in the database
world.
Brief History of SQL and SQL Standards
As discussed earlier, pre-relational databases did not have a standard set of commands to work
with data. Every database either had its own proprietary language or used programs written in
COBOL, C, and so on to manipulate records. Also, the databases were relatively inflexible and
did not allow any internal structural changes without bringing the databases offline and rewrit-
ing tons of code. That worked more or less effectively until the end of the 1960s, during which
time most computer applications were based strictly on batch processing (running from begin-
ning to end without user interaction).
Humble beginnings: RDBMS and SQL evolution
In the early 1970s, the growth of online applications (programs that require user interaction)
triggered the demand for something more flexible. The situations in which an extra field was
required for a particular record or a number of subfields exceeded the maximum number in the
file layout became more and more common.
For example, imagine that the
CUSTOMER record set has two fixed-length fields, ADDRESS1 (for
billing address) and
ADDRESS2 (for shipping address), and it works for all customers for some
period of time. What if a customer, who owns a hardware store, bought another store? Now this
record must have more than one shipping address. What if you have a new customer,
WILE
ELECTRONICS INC.
, which owns 10 stores? Now, you have two choices. In the first case, you
can take the whole dataset offline, modify the layout, and change and recompile all of the pro-
grams that work with it. This would satisfy the needs of the customer with 10 stores, but all cus-
tomers with just one store each would have nine unnecessary fields in their records (see
Figure 1-4). Furthermore, you cannot guarantee that, tomorrow, some other customer is not
going to buy, say, 25 stores, and then you’ll have to start over again. The second choice is to
20