Bagel Belly Blog

XML vs SQL, RDBMS vs NXD

What do you do when your data is a mix of structured content and relational?

This is something we've been struggling to come to grips with in our latest projects. Much of the content for these projects is quite obviously suited to an XML database, and yet we still have all the mundane things that call for a relational database (or worse - perhaps we should have a relational database and an LDAP server?).

Splitting content across more than one repository or store leads to headaches. You suddenly find it difficult to handle issues such as referential integrity and atomicity - things that you often get for free in a good relational database.

The real problem is perhaps that there simply aren't any good Free relational databases that provide for XML in quite the same way as the big commercial players such as Oracle or DB2. Postgres certainly seems to lack XML support.

I don't think I'm ready to give up XPath and store my XML as big chunks of text in an RDBMS. But neither will I give up SQL. What to do?

Jon Udell seems to suggest a mixed economy is best, while Dare Obasanjo says:

Sometimes I wonder whether developers would prefer an über-language with everything and the kitchen sink integrated into it. Would developers really prefer that instead of having divergent query languages we just had one (i.e. SQL) with proprietary extensions for the different data domains which was used ubiqitously everywhere to query XML documents, in-memory objects, relational databases, text files, etc?

There's a lot to be said for an über-language, but I don't think that's what I want. All I'm looking for is a sane way to handle complex markup and relational data in one application, without having to run two different database systems.

Hmm.

Posted by savs at November 26, 2003 11:34 PM