[sorry for the broken References - I've just joined the list and am replying to a post in the archives]
On Sat, 15 Jun 2002, Perrin Harkins said: >> An Object-Relational mapper takes objects and stores them in a relational >> database, as transparently as possible. I think the most pure example of >> this I've seen in the Perl world is Tangram (www.tangram-persistence.org). >> SPOPS is also an O-R mapper (actually, its a generic Object persistence >> mechanism but it seems to most feature-rich when used with an RDBMS). >> A Relational-Object takes a relational database, and provides access to it >> (select, insert, update, delete) via objects. Class::DBI, Alzabo, and >> DBIx::RecordSet are examples of such a beast. > I would actually put Class::DBI in with the first set. 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. > To me the difference is not O/R vs R/O, since both of them go both > directions. Rather it's a question of what you're modelling in your > objects. I think one of the main differences is in what ways you want to be able to manipulate your data. With an R/O approach the Perl classes are just one of the possible views into your data. If you feel like it you can also do your normal SQL type things on it. In fact one of the deliberate strengths of Class::DBI is that you can very easily port an existing "roll-your-own-SQL-in-Perl" approach over to it gradually. With O/R approaches the object is usually the primary source of the data and the database is just a temporary storage system used for persistence. You probably _could_ go executing arbitrary commands against the database, but it's frowned upon. > 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. It assumes that you're going to create your database schema in a way that these are fairly much interchangable. Tony
