XML db vs Relation db

[hobbes]

@RBARAER:
Neither meant the above as a joke nor as a warning - only sought to give a more objective idea about XML, for itself and for its role in the database, as the linked article seemed unfairly biased. Do not see contention with the points you make: largely agree with you!

The key advantage of XML is interoperability, and where that is the deciding factor about the mode of data transfer, one opts for XML despite its size. If one can have a proprietary protocol which uses smaller-sized files - interfacing systems agree on it - one could easily do without XML.

Unfortunately typical EAI projects do not provide this kind of choice as interfacing systems are pre-designed and/or different technologically and/or exchanging common data files with multiple systems not just what we're building, and so one is not empowered to say let's have a customized protocol for us.

Given that the mode of transfer, for good or evil, is XML - the question now is: how does one store it in the database - dump the entire file in native form, or parse and store it relationally? The choice I'd say should depend on what is to be done with the data next. Is it to be accessed through queries, modified? Or is it to be retrieved only as XML, perhaps to be transferred to another application in its original form at a later time? In the first case, relational storage is the obvious choice; in the latter, XML DB. [Note that XML document fidelity is lost if data is converted to relational form. If one ever needs to regenerate the XML document, it makes sense to store it in native form as well.]

As you state, XML DB cannot hope to match up to the content management features that relational DB provides. Couldn't agree more - but I think of XML DB not as a substitute for relational DB but as a supplement to it. That's the way Oracle has designed it too: it supports XDB in addition to its relational features, not as a replacement for them, doesn't it?