On Thu, 13 Jun 2002, Rob Nagler wrote: > Most OLTP applications share a lot in common. The user inputs data in > forms. The fields they edit often correspond one-to-one with database > fields, and certainly their types. The user wants reports which are > usually closely mapped to a table/view/join, i.e. an ordered list of > tuples. > > A reasonable O/R mapping can solve this problem easily. Like Perl, it > makes the easy things easy and the hard things possible. The bOP Pet > Shop demostrates how you can build a simple application with only a > couple of custom SQL queries. The rest are simple joins and CRUD. If > you need more complex queries, there are escapes. You still probably > end up with a list of tuples for your reports. The key we have found > is avoiding indirection by naming fields and models the same in SQL > and Perl objects. This allows you to seamlessly switch between the > two.
The Pet Shop has a grand total of 13 tables. How well does this approach work with 90 tables? How does it handle arbitrary queries that may join 1-6 tables, with conditionals and sorting of arbitrary complexity? > We've found the O/R mapping to be an indispensable part of the > system. Since all data is contained in objects, the views/widgets > don't need to how the data is populated. They access all data through > a single interface. I'm not a big fan of O/R. I prefer R/O. But to each their own. -dave /*================== www.urth.org we await the New Sun ==================*/
