Foundation for Object / Relational Databases: The Third Manifesto

The purpose of a political document is persuasion, and although they make some good points I wasn't convinced. All of their arguments are based on theoretical elegance. What's really needed is an extended example showing how a practical database would be more easily modelled using their theory. I was left wondering whether a "theoretically correct" database would actually be easier to build and maintain than the ad-hoc systems we have today - many a theoretically elegant language turns out to be too difficult to use in practice.

Also, the authors dismiss some opposing arguments without really understanding their benefits. For example, Appendix B describes how to make a relational view based on a table of object values, which seems like a nice way of having your cake and eating it too (since you can have encapsulation and inheritance). But after bringing it up they dismiss with "what purpose would be served?" I was left wishing it were an online discussion so I could argue back.


Help me on this one   May 17, 2000
 5 out of 27 found this review helpful

The Third Manifesto spends most of its time ranting about the authors' disapointments with industry-leading products like Oracle 8.0i and Informix. In the first chapter, they present example of a nested table object, a standard OORDBMS feature, then excoriate the capability as not being 'relational'. They take unctuous umbrage at anyone who would dare to violate their view of the relational model. Beyond this, I could not follow the logic of their arguments against these types of constructions, because they do not use the scientific method.

I would have liked a more mathematical or scientific description of their arguments. For instance, they expend alot of words on the object movement, but they do not make their topic any clearer with definitions and words. Despite using quasi-mathematical arguments, this is not a work that would stand up to rigorous academic defence. None of the terms are defined. There is no presentation of theorems or lemma, as in Donald's Knuth's books.

This is one of those books the reader has to 'get'. As a systems architect and database designer, I am getting a bit tired hearing about null field discussions and the lack of proper relations in SQL. I guess this group would say that the systems we design are not valid. If you need to hear the arguments of DB2 and relational bigots, then this book may be usefull to you. Otherwize, there are many other text books to read to improve and develop your design skills.


occasional gems in an incomplete work of standard pomposity   September 18, 1999
 14 out of 44 found this review helpful

While Date's elementary database text is an ageless classic and his first series of collected RDBMS writings is rich in original material, the current volume is a profound disappointment. Date and his cohort, Darwen (who tries too hard), derive material from a litany of sources, yet the litany is rather more remarkable for some of its patent omissions than for its completeness. Once again, Date has steered clear of security considerations, and--where he dares to address them--he continues to confuse the most basic terminology, sounding, as it were, like Fernandez and Wood reanimated on tetrodotoxin and living in some bizarre Winogradesque world of datasets and clusters. I wouldn't complain about this ignorance were it not for the overwhelming and inescapable pomposity that cloys nearly every paragraph. I truly wish Date would stop characterizing everyone who fails to embrace his parochial cosmology as a latter-day Hitler, or stop trying to build a career out of hackeneyed digressions about flawed SQL implementations of trivalent logic, etc., a la some Sandhu beating his head against the wall studying the same polyinstantiated three-tuple m-relation for fifteen years. A possibly tangential point, but one worth noting: the reader gets the impression that Date has not designed--let alone coded--an end-to-end DBMS application with graphical support, data distribution considerations, etc., for more than twenty years. As someone who can both theorize and build systems, I prefer to read authors whose gratuitous deprecation of others' work is backed by palpable (read as "operational") achievements.


A serious, rigorous book about what a RDBMS should be.   March 4, 1999
 32 out of 34 found this review helpful

Mr. Data and Mr. Darwen have much to say in this book. The question is will community of "database" people read it, assimilate it, and get to sufficient mass to discuss the merits of the concepts described in this book? And, if that does happen, will it be too late to implement any of the concepts in a real DBMS?

There is no question that there is a rather heated debate about the "virtues" of the relational database model vs. the object database model. Both sides throw rocks at each other: The "object-landers" say the RDBMS is too slow, and has too much "impedance", and besides "you people are fighting a rear guard action"! And the "relation landers" say the ODBMS is too data dependent, chases pointers all over the place, and is just a "CODASYL" DBMS with a pretty face! Meanwhile, the vendor's of both types of DBMS adopt and implement features from the other camps product.

What is refreshing about this book is that it attempts to get away from the "rock throwing" and get to some new and deeper understanding of what an RDBMS could and should be. And, it does not apologize for advocating the relational model.

This book is not casual. It is rigorous, and the reader should have a good foundation of database theory to get the most out of it.

I came away with three main themes after reading this book:

Support the relational model, and define what an "object' is and where it fits into the relational model. "Object" = Domain = Data Type. Enough said.

Define a more "relational" query language - let's call it "D". (Why not "D++" to really get em going? Sorry, we are being rigorous now!) Mr. Darwen and Mr. Date never were big SQL fans. So, they give us a new language that they claim is better and is backward compatible with SQL. Again - enough said.

The API to a database is just as important as the DBMS' core engine - but they are different things. This is something that I never questioned as DBA or as "code jockey". The claim from supporters of the ODBMS is that one of the problems with the RDBMS is that the database language is soooo different from the programming language. And, they are right! People that support the RDBMS (I'm one of them) spend a lot of energy trying to defend the RDBMS on this issue. This book makes the point that it's not the RDBMS' fault. There is nothing wrong with the conceptual model of the database. It is the Application Programming Language (API) that is the problem. But, as Date & Darwen emphasize here - these are logically different things. We should not "dumb down" the database access to support the model and architecture of the programming language.

Steve Wilson sawilson3@ems.att.com