Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XML Database Decision Tree?
 >Paul T >If the process of dismantling / re-assembling is really fast and >robust ( no parts would get lost ), the advantage is that you can >park 10-1000 times more cars in the same space. And perhaps >have more trees in downtown as a side effect. I'd be very interested in seeing a realistic example of how this theoretical advantage could work. Of course if cars could be stored in RDBMS, you could store each type of screw, nut, bolt, bearing, etc. just once and save storage... but you'd also have to store all the relationship information to specify where all those parts go. In "native" XML, those "part-of" relationships are implied by the containment hierarchy. If the redundant content had much more information than the description of where it went, you could get the space advantage, but you would have awfully boring documents! Of course, if there is a LOT of redundant information in an XML document (e.g., boilerplate text), XML has XInclude, embeded XLinks, external entities to address this common problem. What native XML (in or out of a database) doesn't have is a good discipline for referential integrity between the entities and references; indeed the InfoSet and XPath data model doesn't expose the fact that all the bits of boilerplate came from a single source. I'll freely admit that if the boilerplate is changing and you want to query on the contents of the boilerplate (e.g., find all the documents that include an XInclude'd policy document containing the string "irradiate all mail"), the RDBMS solution is superior to the (nonexistent?) native XML solution. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
