good chemistry is complicated, and a little bit messy -LW |
|
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
I see two uses for "object-relational database programming" - one as a simple storage solution - I have seen people claim "we store everything in the database", and meaning "we have a huge blob field in the database where we serialize our objects into", and one as a thin layer above the database tables. The first approach doesn't necessarily need any database as backend, and to me, the second approach only makes sense if it makes sense to think about your data per row, instead of thinking about your data as sets and manipulating whole sets. Personally, I use Class::DBI mostly in the first sense, as a simple persistence solution, but as Class::DBI allows me to use SQL statements directly, I can switch between a row-based view of my data and the set based view that SQL allows easily. There is Class::DBI::IsA, which implements "inheritance" for Class::DBI objects in the sense that you can have different tables that add attributes to some of the rows without the clumsyness of actually needing to check for the existence of the row in the secondary table, which to me is the main point of the so-called "object databases". Upon rereading the parent, I see that you want a comparison between DBIx::Recordset and Ace - I only heard of the former and never even heard of the latter. I don't like DBIx::Recordset, because I don't like needing to remember the order of my update statements and always ended up writing a specific class interface in the Class::DBI style for my row-based transactions. I have no experience in object oriented databases, but I haven't needed them yet. I think that the approach taken by Class::DBI::IsA and the Everything engine is "good enough" for all my inheritance needs. In reply to Re: object-relational Perl programming: best practice or compromise?
by Corion
|
|