<< 1 >>
Rating: 
Summary: Not so good?
Review: I find this book poorly written and inaccurate. Here's just one example of a confusion (page 48): "A database object may have a different OID each time that it is loaded onto the heap (memory)... Each time an object is created, a unique OID (object identifier) is added to the OODBMS (object-oriented database management system) identifier table. When an application references an object via its OID, the OODBMS converts the OID into a virtual memory address. This means that the object can be found quickly regardless of where it is stored, i.e., local memory, a remote hard disk, or on a device in a networked system... An OID once assigned to an object by the system, lasts the lifetime of an object." So does the OID change when the object is loaded from a hard drive into memory, or not? What is the "lifetime" of an object: its entire existence, or only so long as it hasn't been garbage collected from memory? I find the above highly confusing! And there are many more examples like it. The text is also highly repetitive; the acronym "SQL" and its "translation" is introduced three times on pages 45-47, each time as if it has not been talked about before. A good copy editor would have helped, too. The use of commas where semicolons would have been less confusing is just one example. In sum, while there are gems in here, there's a lot of overburden.
Rating: 
Summary: Excellent overview of database object models
Review: I have been looking for some time for a text that explains all of the nuances of OO and how it applies to databases. This book does a wonderful job in explaining how objects work with RDBMS, and it really helped me to understand the concepts of polymorphism. I also enjoyed the section on impedance mismatches.
Rating: 
Summary: Fails to convince
Review: This book reads like a sales pitch, but whatever advantages OODBs have are not made any clearer in this book. The book admits early on that an OODB is more brittle than a RDB, and then states that the advantage is that you can now "associate behavior" with objects in the database, but this has been possible with RDBs for awhile (admittedly not in any portable fashion). This is typical for the book. As is confusion between implementation and the underlying model. Additionally, explanations of concepts like "object" and "method" (and other terms) are rather fuzzy. The book tries to create the appearance of balance, but it is so obviously trying to push objects that the clarity of thought and presentation suffer. In my view objects are obviously useful, but the theory for them is not worked out yet. Until then, they can fit neatly within a relational framework. Bluntly: a new database model is not required, just better implementations. Verdict: Not Sold. Neither the argument, nor the book (I skimmed it at the local shop and saved myself the expense).
Rating:
Summary: Fails to convince
Review: This book reads like a sales pitch, but whatever advantages OODBs have are not made any clearer in this book. The book admits early on that an OODB is more brittle than a RDB, and then states that the advantage is that you can now "associate behavior" with objects in the database, but this has been possible with RDBs for awhile (admittedly not in any portable fashion). This is typical for the book. As is confusion between implementation and the underlying model. Additionally, explanations of concepts like "object" and "method" (and other terms) are rather fuzzy. The book tries to create the appearance of balance, but it is so obviously trying to push objects that the clarity of thought and presentation suffer. In my view objects are obviously useful, but the theory for them is not worked out yet. Until then, they can fit neatly within a relational framework. Bluntly: a new database model is not required, just better implementations. Verdict: Not Sold. Neither the argument, nor the book (I skimmed it at the local shop and saved myself the expense).
<< 1 >>
| 
