Using a Native XML Database

Various aspects of using native XML databases are important to introduce briefly :

• Storage in native XML databases:  XML documents can be stored in a database as a large string, a binary object, or in some kind of XML data type. Some relational databases allow storage of strings as much as 4,000 characters long. For the unpredictable nature of the length of XML documents this is usually inappropriate. Binary objects can either be straightforward binary storage (BLOB data types), or specialized binary-stored, very large text objects, sometimes known as CLOB (Character Large Binary Object). Size for CLOB data types is usually restricted physically, as in 4GB, as opposed to string length. Additionally, unlike long strings or BLOBs, CLOBs usually allow some type of text searching and pattern matching within them. However, any CLOB pattern matching is no match for XML-enabled functionality of XML data types. Some relational databases allow storage of XML documents in their entirety into XML data types, with full XML enablement. Obviously, a purpose-built native XML database should allow full enablement of XML functionality as a part of the storage of XML data.

• Concurrency, locking, and transactional control:  Native XML databases, in the form of XML data types in relational databases, or otherwise , will likely support locks at the XML document-level only. So, the larger your XML documents, the worse your concurrency and multi- user capacity will be. Node level within XML documents is certainly a possibility but just imagine implementing it. Node level locking would certainly need validating and enforced schemas; and there goes your flexibility, right out the window, right off the bat! And it gets even worse because XML documents are by nature hierarchical, and thus any node level locking requires locking of all existing parent nodes at the same time. Node level locking is not really an option with existing technology. How you structure your XML storage essentially depends on application requirements. The larger your XML documents are when stored, the less capable your database will be as a multi-user environment. A single XML document Native XML database is only a single user environment.

• Reading native XML databases:  Reading data from a native XML database, or XML data type, can be performed using specialized tools. These tools include things such as XPath, XQuery, flat text file parsing, and all the goodies presented in Chapters 5 and 6. Some of the functionality presented in Chapters 5 and 6 is, in actuality, an implementation of more generalized functionality such as XPath and XQuery. XPath and XQuery will be covered explicitly in later chapters.

• Changing content in native XML databases:  There are numerous tools and functionality available for changing XML document content. As you saw in Chapters 5 and 6, some of that functionality is more sophisticated in some cases than in others. As far as standards are concerned , XQuery will eventually allow updates (even though it is entitled Query ). There is also something called DDML. You can also use precise access to XML document content using XML schemas, DTD, and the XML DOM.

This chapter has introduced some very basic concepts and ideas behind the architecture of native XML databases. In fact, it might be surprising to realize that an XML data type, as stored in an Oracle or SQL Server database, is actually a native XML database in itself. In addition, much of what was discussed in Chapters 5 and 6 for Oracle and SQL Server database, respectively, will be covered in later chapters under the guise of topics such as XPath, XQuery, XLink, XPointer, and otherwise.