When I was younger i was amazed at how you could easily create multiple software layers to hide the underlying data. This was called abstraction and it was called good. In those days when data was stored in B-trees and we had to use ISAM or hierarchical databases, we had no choice but to rely on higher level abstractions to make sense of the low level bits and bytes.
Nowadays, I often call such abstractions crud, accumulated dirt from over-design. Modern relational databases provide us with a good set-based metaphor for storing and managing data. In the last 30 years, excellent scalable techniques have been developed to model that data. But we are still trying to force data into more complicated abstractions using object-oriented metaphors when we should be dealing with set-oriented results.
A classic example is this article on using Perl::DBI at perl.com. Every one of the operations that the author discusses can be more clearly and succintly done by using SQL aggregate functions than using a Object-Relational interface and iterating through the records.
Do Objects Hide Implementation Details?
Some people say that Object-Relational is good because it allows us to hide the implementation details. More crud.
The most common change is to add a new field to the database. This means we need to add a new field to the object-relational system, and we need to add code in our software to make use of the new field - so where is the data hiding? It's irrelevant.
The other common change is when we rename or redesign the table structures and we have applications that use the legacy data format. The best way to cope with this change is to use database views and instead-of triggers or rules. This ensures that we show a consistent view of the data to all applications, instead of changing the 10 Object-Relational interfaces for the 10 applications that feed on that legacy data.
Is Combining Data and Methods Good?
The other argument for Object-Relational is that objects combine data and methods to obtain better data-coupling... Yeah, like a strait-jacket. You can also argue that separating your data from your code is better because it makes everything more loosely-coupled, and therefore your code is more reusable. Combining functions that deal with a specific type of data into an object makes sense, but it does not necessarily mean that the data should be in the object too.
The mistake here is in believing that the OOP approach is generally superior to the set-based way, hence the misconception that the programmer should generally avoid using SQL. Of course for every pundit that says something there are exceptions. Here are some examples of where Object-Relational is the way to go:
(1) where the data relationships are richer than data; for example in a manufacturing system where there are a few components but many ways to assemble them.
(2) where the underlying database provides few abstraction features (eg. BDB or ISAM).
Additional readings from Database Debunkings. In particular Fabian Pascal's OO for application development, not database management and Oh, Oh not OO Again. They are hard to read, and might require further research to understand, but the payoff in terms of your design skills is fantastic.
Postscript: After thinking a bit more about object-relational technologies and looking at implementations (j2ee, zope), it appears that an in-memory object store is an important part of this technology. It ensures reasonable performance because you don't have to dig into the database every time to access an object (of course data synchronization becomes an issue). PHP doesn't have this feature currently. So from a PHP performance perspective, O-R makes even less sense. (Added March 2003).
Tim Bray, co-inventor of XML says (added 19 July 2004):
Lots of architects have learned, painfully, that you usually canâ€™t magick relational rows away behind object/class abstractions. The right way to think about a database is as a set of normalized tables that are designed to be addressed with SQL strings.