Tony Bowden wrote: > I'd have to disagree. Maybe Mike had something different in mind when he > created Class::DBI, but as the current active developer on it, I'm > definitely pushing it in the R-O direction. Like Dave, I always start by > thinking of my database schema and then Class::DBI provides a way to > translate that, table -> class, row -> object, column -> method. Throw > in some simple relationship builders and a sprinking of syntactic sugar, > and that's pretty much there is to Class::DBI.
Tangram may have loftier goals, but in general that's pretty much all there is to any of them. And I don't think that the angle you approach your data design from -- classes or tables -- has much bearing on which tool you would use, with the possible exception of Tangram. SPOPS is explicit about wanting to support legacy schemas without changes. I think that in this realm there is Tangram, which tries to bring some extra stuff like database modelling of object inheritance and queries written in perl, and everything else. >>Things like Tangram model the domain objects, i.e. concerts, >>seats, people. Things like Alzabo model the database objects, i.e. >>tables, rows, foreign keys. > > I think on this front they both try to do both. Class::DBI does anyway. My casual perusal of the documentation certainly made it look like Class::DBI hid a lot more of the database stuff than Alzabo. After the configuration is done, the database concepts like foreign keys are never explict. I guess my point here is simply that I think there isn't so much difference between most of these tools and that characterizing them as being anti-database or too heavy is not accurate. As a sort of wrap-up to this round of O/R technology discussion, I want to post a link to this quote from the author of SPOPS where he talks about the practical limitations of SQL abstraction. I thought it was a pretty astute observation: http://perlmonks.org/index.pl?node_id=162259 - Perrin
