Digg This!

Page 1 of 2   next page »

Developers tend to use the most familiar technologies. For data storage, that is the relational database. During design it's easy to see tables of data everywhere; however, not everything is relational in nature. When dealing with XML data or data easily expressed as XML, XQuery-based native XML databases (NXDs) present a viable and cost-effective alternative to relational databases, file system storage, or custom developed storage implementations. So, when is it time to consider an NXD?

Can native XML databases really provide a better answer for your data storage needs? In this article we'll examine some guidelines to help answer that question.

When to Consider a Native XML Database

1. Do you have thousands of XML files?
2. Is your XML data larger than 200MB?
3. Are you trying to build a hierarchy into tables?
4. Could your data change over time?
5. Have you spent more that $100 on books explaining SQLXML?

The File System Isn't a Database
The first two questions are practical in nature. If estimates indicate more than 1000 XML files or 200MB of XML data exist, the file system isn't the right tool for the job. File systems are not built to manage large numbers of files in a single directory or huge directory hierarchies. Managing concurrency, out of disk space conditions, and other common problems will plague your application unless you use a database.

Naturally Hierarchical
The third reason to consider an NXD really has to do with the impedance mismatch between relational databases and XML data. Fundamentally, XML data is hierarchical and is a poor match for a relational database's rows and columns. Relational databases have always had a hard time modeling hierarchies. You'll find dozens of workarounds for this, but no real simple and efficient solution. Any XML-to-relational mapping tool will have to pick one of these techniques and manage this common case as best as possible. Regardless of the solution, performance will suffer. The end result will also be more brittle over time. Changing the structure of the data - which is easy, natural, and useful to do in XML - forces a redesign of the relational database and changes to the mapping layer. A single mapping mistake could completely skew an entire data set. As an XML document structure changes over time, it's possible for attributes to become elements, and vice versa. Over time, incremental changes to the logical structure of the XML data can force physical changes to the database, and wholesale dump and reload may be required of the relational system to keep pace.

Structured Yet Flexible Data
The fourth question suggests that requirements change over time, something true of most real world business systems. Once a relational database schema has been set in stone, only the database administrator (DBA) is qualified to change it without disrupting services. The contract between a relational database and the program that use it becomes the weakest link in the system. As requirements change, the DBA will spend endless hours mitigating the issues that arise. Contrast that with XML databases. XML is both structured and flexible. Even XML documents conforming to a DTD or XML Schema maintain a high degree of flexibility when compared to relational schemas. Most NXDs will optionally validate document structure. Even when document validation is not enforced, XML documents maintain a high degree of implicit structure. Therefore in either case, XML documents are flexible and structured and as a result the contract between the database and the programs using it is not brittle. It can withstand change without requiring a DBA.

Data Mapping Is Wasted Time, Money, and Effort
The last question is really a reality check. Take a second to consider the amount of time and money you've spent trying to make a solution workable. The best thing you can do when digging a hole is to stop digging and get out of the hole. With that in mind, let's look at SQLXML. If you need to mix and match SQL data and XML data, it's not a horrible way to go. However, if you view it as a way to squeeze XML into a relational system in which you've already invested, you might want to reconsider. You are going to pay a performance penalty for every document stored in terms of CPU and memory. Your ability to query, index, and optimize will be impacted as well. Executing XQuery against XML data mapped into relational tables will be hindered by the non-native storage format. An optimized native XML database won't have the same penalty.

Let's take a look at how to use an NXD to learn more about its advantages over a relational database.

Examples and Code
Berkeley DB XML is an open source XQuery implementation built atop the Berkeley DB transactional database system. It supports optimized XML storage, XQuery query planning, massive scale and concurrency, and is available for download as source code for multiple platforms and as a Windows installer from Sleepycat Software (www.sleepycat.com). Berkeley DB XML has also been integrated with Stylus Studio if you're more comfortable using an IDE for development. Berkeley DB XML is readily available to anyone, so we'll use it for the following examples.

First let's create an in-memory container for XML documents. Follow along using the "dbxml" command line provided with Berkeley DB XML.

dbxml> createContainer ""
dbxml> putDocument myDoc <names><name>joe</name><name>fred</
name><name>jane</name></names>
dbxml> query collection('')/names/name[.='joe']
dbxml> print
<name>joe</name>

Line 1 creates the container, while line 2 places a simple document into the container. The third line performs a query on the container returning each document that matches the XPath query /names/name[.=joe]. Finally it displays what we returned by the query statement.

That's all quite useful, but let's say that you need to access your XML storage programmatically. Because Berkeley DB XML is a library, and as such is linked into your application just as any other library would be, it does not incur the overhead of client/server communication. You interact with Berkeley DB XML using one of the supported language APIs. The primary one is C++, as the product is written in C++. Java, Python, Perl, PHP, and TCL are all supported API languages. Many other languages are supported by third parties and are readily available on the Internet.

With that in mind, let's next try some simple C++ code that calls for the same thing as the dbxml commands used in the previous example (see Listing 1).

The underlined sections of the code relate back to the first example. The first underlined section creates a container. This container is called 'test.dbxml,' and is on disk, and rather than in memory. The next underlined section places the same simple XML document into the new container. The last underlined section issues the query, and the while loop equates to the print statement. Put it all together and you have essentially the same result as before. In Java the code looks much the same; again the underlined areas are the common key sections of code (see Listing 2).

As you can see, the API is fairly straightforward and similar across languages. You'll note that the C++ and Java examples create a database on disk rather than in memory simply by giving the container a name.

Let's move back to the dbxml shell and try a more complicated example. This time let's add a few documents, so we can explore the performance of the system.

First let's populate an imaginary parts database.

dbxml> createContainer parts
Creating document storage container

That created an empty container and opened it as the default container in the shell. We can now use the putDocument command to run our XQuery and insert the sample data.

Page 1 of 2   next page »