Customers say they want them, vendors are scrambling to provide them, and opinions vary as to how to set them up correctly. They are XML databases, a way to store, search, and retrieve all that mission-critical business data that is finding expression in XML format. Currently, XML rivals HTTP, HTML, and SQL as one of the big hits on the top 10 chart of information management standards.

But XML's strength, its great capability of facilitating the flow of semistructured data among applications and heterogeneous systems, also introduces several new problems. One of the more pressing problems is how to store and manage XML data.

"There are really three ways you can do this," says John Matranga, CTO of Omicron Consulting, in Philadelphia. "You can store XML in a database designed specifically for XML, in a modified object database, or in a relational database."

Matranga goes on to say that because the relational database is still the undisputed king, most people will probably choose this option. "But if the relational database does not have XML extensions, you will need to 'teach' it how to handle all the hierarchies associated with an XML document," he says.

In fact, Microsoft, Oracle, and IBM have already added XML extensions to their relational databases, but these efforts will not satisfy everyone for a number of reasons.

"I think most people will want to stick with their relational technology when it comes to XML storage," says Josh Walker, an analyst at Forrester Research, in Cambridge, Mass. "But XML has breathed some new life into the niche market of specialty databases."

A second chance for object databases?

If you are over the age of 25 you may recall that only a few years ago the object database was hailed as the next big thing in data storage.

But outside of some very specialized markets -- high-end science research applications, for example -- the object database never really caught on.

The reason, according to Deborah Hess, senior analyst at Gartner in Stamford, Conn., was complexity. "An object database requires you to learn a whole new language," Hess says. "That is one of the reasons the object database market started to die in late 1995."

It is also why Object Design, an object database vendor in Burlington, Mass., changed its name in 1999 to eXcelon. This was actually the culmination of a project begun in 1997 by then-CTO Larry Alston to make Object Store, the company's database, into a repository for XML documents.

Alston has since left the company, but the commitment to XML remains strong. "The relational database design does not easily support indexing or searching XML," says Satish Maripuri, president and COO of eXcelon. "An object database such as ours offers a more natural way to store, search, and retrieve XML data. This is why we took a bet with XML."

Hess agrees: "An object database stores data in hierarchical form; this enables it to handle all the classes and inheritance properties of objects. Now XML documents are themselves hierarchical, so the two fit very well together."

And Maripuri says the

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine