Re: The relentless march of abstraction

[Ken North <ken_north@compuserve.com>]

>> I've always felt that schema are only needed if you're storing XML
content in a relational database, but so many applications don't require
a relational approach

The use of schemas is not a by-product of relational database
technology -- SQL basically adopted a proven concept. The network-model
database is what gave us schemas and sub-schemas, which defined set
relationships that determined how an application could traverse the
linked nodes in a network.

Sub-schemas were a solution for partitioning data by defining sets an
application could access. For example, assume a bookID node (root
element) having several child nodes (Title, Author, ISBN, Rating,
WholesalePrice). You could create one sub-schema for public data by
defining a set owned by bookID, with members Title, Author, Rating, and
ISBN. That would be the appropriate sub-schema for a catalog display
such as Amazon.com -- the private pricing information is not exposed.

For applications needing to access pricing data, you create a separate
sub-schema and define a set that includes WholesalePrice.

<< there's nothing about XML that requires a relational db

Like any other profession, we need to match the tool to the job. Cutting
down one tree does not require a power saw, but dozens or hundreds of
trees present a different problem.

Most SQL DBMS products moved past relational years ago, so the
appropriate question might be "When is object-relational technology
required?" If I have to open ten documents to find a shipping address
for a package, a text editor, like an ax, is adequate. However, if my
application must search a collection of thousands of documents to find a
location and access geo-spatial data before returning a map image, then
my choice is the power saw, not the ax.