How-to Tips for XML Storage

by Bill Trippe

If you take even a cursory glance at the XML storage market, you'll see many vendors vying for your attention and dollars, including major database companies like Oracle and Microsoft and a long list of companies with specialized XML repositories. The various products reflect completely different approaches to data storage and management.

In fact, XML has reopened some fundamental questions of data storage that some people (certain vendors especially) felt were already answered. For many years, object-oriented database vendors argued that their systems were superior for storing document data, but they never gained much marketshare or mindshare against the giant relational database vendors like Oracle. Customers seemed to accept the argument that relational databases would do the job well enough, and IT organizations wanted to shorten, not lengthen, the list of technologies in use and under maintenance.

Have things changed enough so that you should now consider a specialized database for XML storage? The answer depends on three things: how much persistent XML data you have; whether you need high-performance, real-time access to this data; and what kinds of querying you think you might want to perform.

Persistent XML. Applications use XML in one of two ways: as a source format, or as something that is created and used for exchanging data between two data sources. You may have source XML data that needs updating and maintenance. A good example of persistent XML might be catalog information with product descriptions and pricing. The more XML data you have and the more interaction and maintenance required, the more you need a specialized storage tool.

Real-time access. If the data is stored in a format other than XML and you need instantaneous access to it as XML, then transformation processes can slow down access. For example, if you stored catalog data in a relational database and you needed XML to drive a Web page, the transformation process could impact performance. XML and a database optimized to store it will provide better performance.

Querying. Relational databases support SQL for querying relational data, but SQL won't work with XML. SQL is designed for the row-and-column orientation of relational data. XML data, with its mix of elements, attributes, and textual data, requires a different approach. XML data is queried with tools based on XPath. While relational database vendors such as Oracle have basic XPath support, you may need a specialized repository if you have extensive and complex requirements for XPath-based querying.

If you have one or more of these three requirements, then it makes sense to look at specialized tools for storing your XML. The two market leaders in this space are Software AG, with its Tamino XML Server (www.softwareag.com/tamino/), and Excelon (www.exceloncorp.com), with its eXtensible Information Server (XIS).

Software AG is a long-established database company, having introduced Adabas some 30 years ago. It has made an aggressive and strong entry to the XML market with Tamino. Excelon is a leading provider of object-oriented database technology, and XIS is a mature XML repository complemented with Stylus Studio visual development tools.

Even if you do add an XML repository, you won't be saying goodbye to Oracle or Microsoft any time soon. For one thing, you'll still have many uses for relational data and the tools that work best with it. But as your use of XML increases, your need for specialized tools will increase. As was the case when you chose your relational database, data volume, processing needs and query complexity will drive the purchase decision.

Bill trippe (btrippe@nmpub.com) is president of New Millennium Publishing (www.nmpub.com), Boston, a consultancy specializing in electronic publishing, content management, SGML and XML.