[
Lists Home |
Date Index |
Thread Index
]
We're talking apples and oranges here.
What you're talking about is a generic set of relational tables like
Elements, Attributes, Text, Comments, and ProcessingInstructions. This
is generally considered to be a native XML database implemented on top
of a relational database. In fact, this is roughly how SQL Server
implements their XML data type.
What I'm talking about is a set of tables designed to store documents
corresponding to a particular XML schema. For example, mapping a sales
order document to the Sales, Items, Customers, and Parts tables. While
such tables can, in theory, store things like sibling order, comments,
and processing instructions, in practice they almost never do. This is
generally known as "shredding".
One significant difference between the two is that the first in some way
looks like an XML document while the second is indistinguishable from
other relational data.
-- Ron
Peter Hunsberger wrote:
> On 4/15/05, Ronald Bourret <rpbourret@rpbourret.com> wrote:
>>However, shredding shouldn't be viewed as a substitute for native XML
>>data storage as it doesn't preserve sibling order, comments, processing
>>instructions, etc. and usually doesn't support mixed content. It also
>>requires design-time mapping of the XML schema to the relational schema
>>-- something that won't work with schemaless documents. So it shouldn't
>>be viewed as a substitute for native XML storage but as a complementary
>>technology.
>
> I think you're over generalizing more than a bit. Over the years I've
> done a couple shredding implementations. In particular, I've
> previously built a generalized approach on top of SQL server that
> supported mixed content, sibling order and did not require a schema.
> Adding comments and PI's to that would have been pretty much trivial.
> There's nothing magic here; generalized hierarchical to relational
> mapping algorithms have been around for a long time...
|
