in reply to OO concepts and relational databases
However, I think you underestimate the cost of decomposing table records into instance/attribute/value tuples. There's a reason that large databases have nice records... you tend to fetch the values in those records in clusters, and it makes sense for the database to be aware of that, instead of managing lots and lots of little individual values.
Certainly, there's a programmer time savings to have a transparent Object backing store. But for a large heavy application, having a proper DBA design a proper RDBMS will still be a win with existing popular technology.
There is research work going on about OO storage, but nothing that is well deployed or available, as far as I know. And it won't be about mapping that to an RDBMS. Proper paradigms are required.
-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.
update: Ouch, and after reading another response in this thread, I realized I had completely forgot about typing! A real DBA-designed record contains typing and constraints that ensure data integrity. An ad-hoc system that is merely providing backing store for Perl-side objects will not have any of that meta-information available, and must rely on the Perl side to manage any data integrity and typing rules.