XML and Databases? Follow Your Nose
by Leigh Dodds
|
Pages: 1, 2, 3, 4
Existing Investment
As with any technology evaluation existing investment is an important consideration; investment in developing particular skillsets shouldn't be downplayed. For many applications an XML Database isn't required, existing technologies already provide the needed functionality. Just as many database vendors have added object features to their databases, they'll also add XML features. Adopting a XED or even NXD may be as simple as staying on your current platform, and taking advantage of new features as they arrive. This strategy may be suitable in the cases where you are adding XML support to an existing application, and will end up with a shared repository
If you have a heavy investment in an Object-Relational DBMS (Oracle, MS, IBM) and have learned to live with them, their XML add-on support may well be cost effective for you. If you are starting from scratch, the native XML DBMSs are generally cheaper, lighter, and easier to manage than a "universal server" DBMS. (Michael Champion)
...Why should people currently using RDBMSes for their classic key corporate data have any interest in converting to XML as a data model? After all, the relational model basically serves their needs pretty well. There is not currently an industry crisis among RDBMS users caused by deficiencies in the relational model. Furthermore, changing the data model in such systems from relational to anything else would entail a huge amount of work and risk. A vast superstructure has been built around these relational databases: report generators, reports written for those report generators, all kinds of tools and add-ons from the relational database vendors, the fact that lots of people have been trained in concepts of third normal form, the SQL language, and so on and so forth.
...The image of native XML DBMSes trying to supplant relational DBMSes, trying to take them over and replace them, is a strawman, and we need not waste our time thrashing it. (Dan Weinreb)
If in five years the currently dominant RDBMS vendors support automatic XML schema import/conversion tools, seamless XML instance shredding/storage capabilities, and XQuery as a query language, what will distinguish them from "native XML" DBMSes? Oracle 9i already has a "native XML SQL type". "Native XML DBMSes" will be around, although we may not CALL them that... (Michael Champion)
Multiple Schemas, or even No Schema
The effort required to develop a relational mapping for particular document types (particularly one that will satisfy all your query requirements) can be prohibitive if you have to store documents conforming to multiple schemas or even no schema at all (meaning you have to deal with semi-structured data). When schemas are constantly evolving, particularly when this is outside your control, this problem is exacerbated. In these circumstances the flexible storage options of a NXD are a good choice.
If you have a small number of XML DTDs/schema to work with and can afford the time to do detailed analyses of the storage strategies and build data loading programs, the XML-enabled RDBMSes may be satisfactory. If you have lots of different XML datatypes/schema or you have lots of well-formed XML to deal with, the native XML DBMSes make it much easier to build type-specific collections or efficiently store/retrieve well-formed XML. (Michael Champion)
Speaking generally, the native XML DBMS tends to be more flexible in handling data with no schema, or with evolving schema, than solutions based on normalizing XML into RDBMS tables. (Michael Champion)
The various native XML DBMSes, by diverse means, allow well-formed XML to be stored and efficiently queried without demanding rigid adherence to a schema. Some do this by never defining an XML schema at all or by storing well-formed XML that doesn't match a known schema in a "miscellaneous" collection, some by allowing the schema to evolve and re-indexing on the fly or whatever, some by allowing open content models at any point in the schema, or by some combination. (Michael Champion)
Using XML to describe structured data can be very advantageous when there are multiple data sources... If you do not have complete control over the "schema" or shape of the information that comes from the various servers..., using a schema-independent XML database will reduce your development time and ongoing maintenance burden: you will not have to build and map a [set of] relational schemas to represent all of you various ... sources, nor do you have to maintain that schema in the presence of changes. (Bob Lord)
Round-tripping
What does your XML-database integration smell like? Share your experience in our forum. |
| Post your comments |
When mapping an XML document into a relational database (or even an XED if you're not using a BLOB to store the whole document), it is inevitable that some information about the document will be lost. Native XML databases don't suffer from this shortcoming. Therefore if you require that data must retain its original structure, into and out of storage, then an NXD is the best solution. Round-tripping is likely to be an important requirement when performing enterprise integration and one needs to maintain logs of messages exchanged between systems.
If you want the XML representation to reflect a snapshot of reality (e.g., the XML purchase order is a "contract" that is digitally signed for purposes of non-repudiation), and you don't want the XML representation to change (breaking the digital signature!) when the underlying data changes, a native XML DBMS is generally more appropriate. (Michael Champion)
