Home Guncel Konular Immigration Links Downloads Support Sample Programs E-Business Docs About Me RDBMS vs. Native XML Storage XML Data Works Best in a Hierarchical Database XML is hierarchical in nature. Tamino was designed by people who have worked with high performance hierarchical databases for years. It is NOT a new version of Adabas! It is completely new code written specifically for XML data that uses years of experience in how hierarchical databases work. No other company has that expertise available to it and it is the reason why Tamino has such a performance advantage over relational databases. XML-Enabled RDBMS Support XML as an input/output format with conversion Performance reduced due to overhead of transformation Conversion from XML to SQL worlds means longer time to market (dev costs) and very high administration costs Transformation capability limited to implementation of particular vendor - standards evolving Retrieval: Search capabilities limited to what can be mapped from XML to SQL and vice versa Not eXtensible: If relational structures have to be changed, adaption takes much longer than with native XML storage Good: RDBMS can be queried with SQL. No extra learning! Simply put, XML is hierarchical in nature, not relational. To make it fit into a relational model one has to do a great deal of work. A great deal of that work is up front and can significantly impact the cost to deploy an XML solution as well as considerably lengthen the time to market for your XML solution. Any of us who work with computers I think have a high degree of paranoia about relying on them to do things with no glitches. The decomposition of data from XML into a set of relational tables and recomposition back from those tables to XML is a prime opportunity for such glitchesAfter all the work is done to get it to function correctly, the pain of making any changes is such that people lose several of the great benefits of XMK, flexibility and extensibility, in other words, the ability to use information the way we do in our day to day work.Probably the largest concern is that the process of decomposition and recomposition puts a very significant overhead burden on the database and performance suffers as a result.Finally, rich content is often a mix of XML and other data types. Once the effort is made to twist a relational database into a form that can handle XML, it adds a whole new level of complexity to then add the ability to manage multiple types of other data as well. Lets drill down to each of these points. Native XML DBMS Support XML as an input/output format as well as native storage -> performance Performance improved due to no transformation Conversion between two worlds is not required by developer or administrator Native support for standards imply faster response to standard evolution Retrieval: Native XML search capability supported - increased search performance (competitor is a mouse click away) Extensibility: XML metadata changes handled elegantly Basic Arguments Against RDBMS (I) Relational DBMSs are designed to work with relational data If the data cannot be easily normalised then a relational solution is bad Quote: “Without the object relational extensions very complex structured XML cannot be stored!” Source: Article by Oracle Basic Arguments Against RDBMS (II) Relational DBMSs cannot cope with the complex hierarchical / nested structures available with XML too many tables too many referential references too many foreign keys too complex joins too cumbersome queries no object locking Basic Arguments Against RDBMS (III) Relational DBMSs offer multiple storage options because none is good BLOBs cannot easily be queried BLOBs cannot easily be updated Storing the XML data in multiple tables has a performance overhead that means that the use of this approach should be kept to a minimum definable structure, is stored as a monolithic block. Using the file system this way provides acceptable functionality, and therefore wins out because it is extremely easy to implement. There are a number of tools that build on the file systems functionality, and file systems are included in operating systems at no additional charge. XML, however, has very different storage requirements. XML applications must store and index the fine-grained elements as well as the document structure. In addition, they must be capable of linking these fine-grained elements directly to each other and to a variety of data types containing associated information. The increased demands implied by this functionality mean that additional care must be taken to build a system which scales under increasing load. Attempts to parse XML data of any complexity would overwhelm the capabilities of the file system to maintain the rich linking structure and semantics of the data. Of course, the alternative is to store the XML data as BLOBs and then parse it on the fly each time it is used. This results in sub-optimal performance, because of repeated parsing. In addition, once the data were parsed, the file system could not execute the complex data manipulation required. In addition, this BLOB storage approach undermines the ability to link various disparate elements into a rich tapestry of information that models real-world usage cases. Of course, implementing all of these features on top of the file system is a possibility, through custom development, but this would essentially recreate object database functionality from scratch.