I’m gonna take exception to this too. Except in very rare cases the *best* ORMs are the ones that don’t let you forget SQL but that instead normalize SQL so you can forget the crappy implementation your RDBMS vendor provides. This is certainly true of Fey and DBIx::Class. Talking with Matt Trout at one point I pointed he suggested that until you saw the SQL through the DBIC you didn’t really get it, and once I started looking at it that way my DBIC usage became *much* more powerful.

I agree with Stevan that if you really want an OO Paradigm that lets you totally forget SQL a graph store like KiokuDB is the way to go. If you have highly related aggregate data then SQL is the right answer and DBIx::Class is my favorite Perl ORM.

First you can’t easily do inheritance, yes there are patterns you can follow to fake inheritance, but they all end in compromise and tears.

Second, there is no real polymorphism available. You cannot treat a Employee the same as a Person because the Employee.id will not be in the Person table. Again, you can fake some of this, but thats not real polymorphism then.

Lastly, because your object data is stored in tuples in a RDB you have no real encapsulation. Sure the objects created by your ORM might be encapsulated but a simple errant SQL statement could bring your whole house of cards crashing down.

In the end a RDB is just a tuple store with implied relationships and Objects are a graph with explicit relationships, they are simply not compatible.

Personally I try to use object graph engines like KiokuDB for my objects and $RDBMS for my tabular data as often as possible.