By Martin Rennhackkamp
DBMS Server Comparison Supplement, November 1996
An Analysis Of The Strengths And Weaknesses Of The Big Six Database Servers.
In 1991 I performed a thorough evaluation and comparison of the four major DBMSs at the time: Informix, Ingres, Oracle, and Sybase. This comparison was done for a client building a huge distributed database application, currently in its second phase of d evelopment, with the first phase running successfully country-wide. At that stage, the distinguishing criteria were query optimizers, triggers, views, and support for distributed databases. Some products had these features, but some others' marketing per sonnel were just talking about them. For example, declarative integrity was a "future" that was at that stage only being phased into most of the DBMS products. It was relatively straightforward to draw up a checklist and fill it in with "yes" and "no" in the various columns. Now, a mere five years later, these aspects - as well as many new features such as Internet support, remote procedure calls, and support for multiprocessor platforms - are standard items on each product's fact sheet and marketing material. On a very high level, DBMS products are becoming such commodity items in IT shops that it is almost possible to take a one-size-fits-all approach. On a detailed level, however, you must do a much more thorough evaluation. The products are evolving at such a fast pace, and their research and development teams are adding new features at such a rate, that simple yes/no entries in the comparison columns are just not enough. All of the comparisons would be similar, with mostly yes entries in each column and the odd no mar ked with an asterisk referring to a footnote saying, "Scheduled for the next release, currently in beta testing." If you want to do a thorough comparison today, you have to study each feature and check the extent to which it is implemented and the qualit y of the implementation. To explain further, I review a few of the features in this comparison supplement. Relational Data Model
Although the DBMS products reviewed here can rightfully claim to be relational, their support of the relational data model must be scrutinized closely. Obviously they all support the basic relational concepts, such as data stored in tables and accessed b y high-level set operations, mostly through SQL. However, not one of the Big Six supports domains. It is crucial that these products address this fundamental concept of the relational data model. You must be able to define your domains and then specify y our table columns, and preferably also your stored procedure variables and parameters, in terms of the domains. This process is necessary to ensure tight type-checking, as you can do in some programming languages. If a "small" (in terms of market share) product such as Interbase could implement domains five years ago, surely the Big Six should be able to "get it right" today. All of the Big Six can rightfully claim that they support declarative integrity constraints. Except for domain constraints, they all support declarative key, column, and referential-integrity constraints. But you must investigate these claims closely as well. Only Informix and Oracle support cascading delete as a referential-integrity constraint violation option, and only DB2 supports the full compliment of set null, cascade, and no action as prescribed by the ANSI SQL-92 standard. You should also check how these constraints are implemented. Most of these products use quite crude mechanisms to implement the constraints. For example, most of them create "hidden" indexes to implement primary-key and unique constraints. In addition, DB2, Informix, and Ora cle restrict you from creating an additional unique index on a column that has already been indexed "behind the scenes" for a unique constraint. Database Objects
All of the products in this comparison supplement support binary...
Please join StudyMode to read the full document