On 4/15/05, Ronald Bourret <> wrote:
> 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.
Well, no, not in our case, but that's beside the point.
> 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.
Given that any general XML schema has a direct mapping to things like
"Elements, Attributes, Text, Comments, and ProcessingInstructions"
you're examples aren't apples and oranges, they're different degrees
of normalization. Thus, the point is; if your going to "shred" you can
shred with as much fidelity to the XML model as you choose to
implement. Whether you end up using a "native XML on top of
relational" schema or some other schema has little to do with the
issue.
--
Peter Hunsberger
