Comparing relational vs. object-oriented database use in content management is highly subjective, and can’t be generalized. That would be like saying that the movie is always better than the book it is based on. Take the Harry Potter series. While the books have been phenomenally successful, the movies are doing equally well at the box office.
There’s not a one-size fits all approach for technology either. Comparing relational and object-oriented databases needs to be done from several perspectives – notably business rationale for the end user as well as technological advantage – not just one.
On the business end, documentation is mission critical, and must be available 24×7. Relational databases like Oracle support application clustering and high availability out of the box. Customers can count on Oracle always being available, and in a global working environment, everyone can get their job done.
Many businesses need to migrate from some form of binary documentation to XML, but it doesn’t happen instantly. Using a relational database, these businesses can store their binary documentation and take full advantage of a CMS while they undertake the process of converting to XML. A relational database can also act as a single repository that stores both XML and binary content, eliminating the need for a separate file system and creates a more homogenous environment for IT.
When business demands and technology realities meet, an argument can be made that a mission critical database application like Oracle requires an amount of care and feeding to be properly maintained. There is, however, also a misunderstanding that with an XML database, an end user can simply let it run and everything is fine.
In reality, many companies like to have control over their “family jewels,” and may want the option of feeding other applications that have canned integrations to relational databases. XQuery may be great, but businesses need to search for content that can be in many forms, XML, PDF, Word, etc. Using a relational database and other technologies, it is possible to support a very robust search mechanism across over 295 different formats.
In both cases, scalability is always a concern. The user must be able to scale and manage both vertically (larger machines) and horizontally (additional machines) while maintaining the integrity of the data and 24×7 access to the system.
Relational databases provide out-of-the-box horizontal scalability, as well as the ability to acutely control how system resources are used. This is crucial in serious business applications. Relational databases can stuff entire areas of XML into a single row (such as a … with hundreds of sub tags). This can be a real advantage, especially if is the users’ only needs are to work with and repurpose that section.
In the native XML database model, the users would end up with hundreds of rows in their database because each tag is stored separately. Even if all the users wanted to do is repurpose a section, they would need to handle every single row.
The proof lies in customer deployments. Many companies have replaced object oriented databases in large part because they didn’t scale. Consequently they’ve been able to grow into very large solutions using a relational database. In fact, one global customer expects to manage a terabyte of data in their (Contenta) CMS by year’s end. Now that’s scalable.
Just as there are many business and technology needs, there are many viable alternatives, including relational and object-oriented databases. To dismiss an entire technology because of one company’s recent acquisition is a blatant sales pitch at best, and technological ignorance at its worst.
