>So to quote Michael again, the problem is
>practical, not theoretical. For example, if you map
>the XHTML schema to a relational schema, the p >element alone is mapped to 36 different tables. As
>you can imagine, reconstructing an XHTML document >requires an impractical number of joins.
This is not strictly true... there are a number of ways of mapping XML onto a relational database that don't require joins... especially given that most real-world documents are not as deeply nested as people might think (typically 3-10 levels).
Speaking as someone that has used XML/SGML databases under CMS systems for years (we have 2 XML databases), one of the main reasons I've seen for it is that real-world documents tend to be somewhat variable, even in very tightly constrained environments where DTD/Schema validation is required (such as the military). XML databases, for the most part tend to handle such variability well (especially those that are schema-independent in their storage). Typical RDBMS-based systems tend to be much more rigorous, and hence, less flexible (though that is not always the case).
The other area where, for documents, XML helps, is with the combination of fulltext and structural queries. Given those capabilities, you can build fairly sophisticated hypertext applications, and also enable fine-grained reuse of content in ways that are difficult in most RDBMS-based systems. The tradeoff here is much like the tradeoff between tightly and loosely coupled distributed systems.
In fact, looking at the list of deployments listed, I would say that for all of these, reuse and flexibility would be two of the reasons people used XML. I bet other factors, such as management paradigm, and ease of integration played a significant role as well.
|
Previous Message
Up
