I'd be interested in this community's thoughts regarding storing object data in a database directly as XML rather than using traditional object-relational mapping techniques.
Ideally, there are individuals out there that have done this to let me know what real world experiences (benefits/problems) that were encountered if you've chosen XML as a data type for your production application(s).
Advantages could be:
- simplified data architecture (store object graphs at a coarse level). An entire object graph would now be stored in the RDBMS as 2 columns: LONG "object-id" and XML/TextBlob "VALUE".
- allow for changes within business model entities with no changes in the DB schema
- provide easy way for object graphs to be communicated among disparate systems (i.e., through web services
Disadvantages could be:
- Simple read requests would have to parse the entire xml tree
- Simple modifications require entire object-graph to be pulled and re-inserted
- May not be compatible with Reporting Tools (no fancy SQL as data is simply XML text)
- Could lead to data corruption (if an item within the XML object graph
Any insights on this would be greatly appreciated.
Actually, your data architecture doesn't change. Only the way your data is persisted...
I think you've got the major disadvantages correct. I would still like to add a specific problem of constrained queries: they cost more $$$ than a brand new Ferrari if you need to read all XML documents into a Java structure and compare the selected elements' values to the search criteria.
"simplified data architecture (store object graphs at a coarse level). An entire object graph would now be stored in the RDBMS as 2 columns: LONG "object-id" and XML/TextBlob "VALUE"."
Yes, but your XML Schema will be just as "complex" or "simple" as the corresponding data model would be. This is not really an advantage.
"- allow for changes within business model entities with no changes in the DB schema "
You still have to change your DTD/XML Schema, and code, which is much more painful than changing a database table. Besides, how often will this happen that you would be willing to incur the numerous disadvantages?
"provide easy way for object graphs to be communicated among disparate systems (i.e., through web services"
Storing XML in the database does not provide this advantage. It just means that the one extra step of converting objects into XML doesn't need to be done. That step is not very hard to begin with. Plus, not every "disparate system" can deal with XML.
It just seems like a really bad idea and an abuse of the already-over-abused XML. Please save all maintenance engineers from pulling their hair out and do not do this. It buys you nothing and costs you a great deal.
XML is a way to communicate, not a way to store, and not an indexed, searchable file format.
XML isn't an indexed searchable searchable format? You better tell that to Oracle.
I think I have the data points on this approach to NOT go forward with this architecture and I thank you for your replies.
I'm in full agreement that XML is way overused, however, I wanted to see what the community thought. Not having seen the latest tools/techniques for Java/XML transformation, I wanted to ensure that no major changes have occured that would warrent the introduction of new uses of the XML data type.
I've read up a bit on the Oracle stuff and recently encountered another project that is struggling quite a bit with the DB XML technology. It seems to suffer from the same performance problems typcially of XML traveral. I don't want to encounter their issues on my project, so for now, I'll wait and stick with the standard RDBMS technique.
We used object-relational mapping software in the first phases of this project with success. I'll stick with that going forward.
I wish to comment on the Disadvantages you figure:
<Yes it is required. But i used the trick for low response time in my current project. I only parse for the mandatory entities initially and rest is parsed at later stage as and when its required. This gives good response time