RE: XML design of Database

Liam R. E. Quin [mailto:liamquin@xxxxxxxxxxxx] wrote:

> Er, there is no one true definition, folks :-)

Speaking as someone else who has a XML database book forthcoming ;), Lee's
absolutely right on this one. While there are some guidelines that can be
used when representing XML documents in a database, blindly following them
can lead to serious performance and portability issues (viz. Lee's
waiting-an-hour-for-a-document example). It's important to consider how the
information is going to be used - are the details of the documents
important? Would it make more sense to keep the documents atomic outside the
context of the RDB and use the RDB as (essentially) an index into the
document repository? Would it make more sense to break part of the tree into
RDB structures and keep finer details as well-formed XML blocks stored as
text in the RDB, or as stand-alone fragments? 

The other problem is that XML documents don't necessarily lend themselves
directly to database representations. This is particularly true for
documents that represent marked-up text. For example, anyone designing a
database to support the following structure:

<!ELEMENT A (#PCDATA | B)*>
<!ELEMENT B (#PCDATA)>

will have a headache handling documents like this:

<A>
  <B>Here's some</B>text embedded <B>in</B> the A eleme<B>n</B>t
</A>

And heaven forbid you're trying to represent this:

<!ELEMENT A ANY>

The moral of the story? Do what makes the most sense, think the problem
through, and don't be afraid to break the "rules".

- Kevin

Kevin Williams
XML Architect
Ultraprise Corporation
co-author, Professional XML, Wrox Press 2000
co-author, ASP 3.0 Programmer's Reference, Wrox Press 2000
forthcoming: Professional XML Databases, Wrox Press 2000


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list