To be honest, I prefer to approach this from the other angle. Namely you start with relations and map logic relating to these back up to your object model. Th

To be honest, I prefer to approach this from the other angle. Namely you start with relations and map logic relating to these back up to your object model. This provides cleanliness of code, performance, and hand-tuned design that you don't get with an ORM. However hand-coding the SQL has some advantages a lot of folks don't want to discuss. While relations and objects are to some extent incompatible, focusing on writing good relational code usually results, at least in anything I write, in a net reduction in codebase size. This is because there are a lot of things that can be done in relations faster and easier than could be done in objects. The answer in my view is not to pick one or the other but to define an interface across them. This is often an ORM in some projects but having talked with some ORM developers I respect, at least some tend to map objects to relations where the relations are views, thus encapsulating the relational logic behind relational processing (which is smart). Again I go almost the other direction. I prefer to define logic interfaces which encapsulate the relational logic and then add a service locator to handle the interface. This was a big motivation behind PGObject::Simple::Role.[1] I am not convinced that ORMs are so bad if they are also used with updateable views (and thus providing a stable interface for the application, protecting the internals of the storage from the application's need for intimate knowledge). However, I personally find it just simpler to write SQL. [1] https://github.com/ledgersmb/PGObject-Simple-Role https://github.com/ledgersmb/PGObject-Simple-Role