[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The relentless march of abstraction
- From: Ken North <email@example.com>
- To: Dave Winer <firstname.lastname@example.org>, "XML-Dev (E-mail)" <email@example.com>
- Date: Tue, 27 Feb 2001 22:27:34 -0500
>> 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.