> My general motto is "tiers eq tears" ... I've never seen > a really comfortable OO/SQL bridge.
So who's talking about an OO/SQL bridge? Not me. At least not an automatic one. I write the SQL by hand. > Group bys, order bys, multi-table selects, locking, SQL query > plans and index optimisation all rightfully belong to the database but are > an anathema to a simple OO/SQL bridge. I use all of those things in my model objects. The model objects use SQL to implement methods like $product->user_comments() or $address->save(), and sometimes it is complex. The point is that the rest of the application gets to the database through the model objects, rather than through SQL. Encapsulation, reuse, blah blah blah. > Generally I try to minimise the layers/tiers/abstraction between > the front-end and the database - for me OO/SQL abstraction is something > akin to 'GOTO considered harmful'. I think you're overgeneralizing based on some kind of O/R mapping tool you've used that tried to do too much. Wrapping up the knowledge of how to work with the database to accomplish certain tasks inside of objects is no different from any other application of OO programming. - Perrin
