In my December editorial I briefly summarized the positions and strategies of six leading RDBMS vendors who participated in the "Great Database Debate" panel at DB/Expo in New York on December 4. I attended the debate; the statements made by the panel members were consistent with the messages I heard during my pre-debate phone briefings. To recap, Oracle Corp., Informix Software Inc., and IBM Corp. are leading the charge by renovating their RDBMSs into "universal" servers and databases. Computer Associates International Inc., meanwhile, rejects this approach in favor of a more "pure" object DBMS and separate RDBMS and other legacy database servers. Sybase Inc. promotes the use of an integration layer that hovers over an RDBMS and other specialized servers. Microsoft Corp. is currently promoting OLE DB as a "universal access" mechanism to any tabular or non-tabular data source accessible by an OLE DB driver.
What's really driving this trend? At least two forces are at work: technical and marketing. I believe that the technical justifications answer real needs identified by customers. At the same time, however, the marketing benefits luring vendors also pose risks for customers.
Extended relational servers are gaining momentum for several technical reasons. Multimedia is proliferating, and the explosion of Internet and Intranet servers is fueling this growth. The traditional approach to storing non-alphanumeric data in BLOB fields runs out of gas pretty fast, especially when you want to perform content-based queries, preferably accelerated by indexes. Object DBMSs often run rings around RDBMSs when complex relationships are required, even if the data is simple alphanumeric values. (Wall Street and the telecommunications industry are two good examples of ODBMS strongholds.) Because modern applications are structured around classes and objects, pouring this data back into a tabular-oriented RDBMS requires more and more mapping and decomposing. Finally, complex data types such as text and spatial (geographic) data that have lived quietly in specialized servers for many years are now enjoying more mainstream attention. These and other arguments make the evolution of extended relational databases seem like a timely and natural step forward.
Even if these technical requirements apply to you, a "universal" server is only one way to fulfill these needs. Using installable user-defined data types can be very appealing, and I think they will work well for many requirements. But before committing yourself to that approach, you should also evaluate specialized servers built to manage a single data type such as text or spatial data. Of course, integrating disparate data is important, but that does not always require a single server.
Today's RDBMS products are sometimes referred to as commodities because they share so many similarities. Logically, a table is a table. Indexes, stored procedures, triggers, space management, and other aspects vary in syntax or implementation, but most of the fundamental concepts are the same. Master any one of them and you will easily get up to speed on another. Even though most real-world applications use proprietary extensions to SQL, you can build applications that run on multiple RDBMS products if you try. For users who want this portability of skills as well as data and applications, similarities among RDBMS products are a good thing.
Customers might appreciate interchangeable parts, but marketing departments cringe. Commoditization drives down prices, and without significant increases in volume, profit growth is hard to come by. Even when volume increases occur, customers can easily be lost to the next cheaper work-alike. On the other hand, differentiation can lock in customers who make significant investments in a product line. If it's expensive to switch, you're a hostage.
The differences between today's RDBMSs are more a matter of degree than of kind. Tomorrow's "universal" servers are likely to differ much more, which will force many customers to stick with what they choose or pay dearly to switch. "Universal" refers only to the data types supported, not to an application's ability to run equally well on any brand of database server.
Even if you accept the technical rationales for extended relational servers, and the marketing motivations don't bother you, it's important to define your business requirements first and then choose architectures and products that meet your needs. Too often, the currently installed product is used for the next project simply because it is there and paid for, even if the application must be force-fit into the technology. As extended relational servers bring major changes, comparing your business requirements to the technology becomes even more critical than before.
What do you think? Let me know via email.