[Dbix-class] DBIx::Class or Rose::DB::Object or other???
Matt S Trout
dbix-class at trout.me.uk
Wed Jun 7 17:55:08 CEST 2006
Kurt Hansen wrote:
> Last summer, I started developing new applications using Class::DBI
> rather than my own home grown DBI modules.
> A few weeks ago, I saw a reference on the mod_perl list to the benchmark
> Rather than sticking with Class::DBI, I am looking to switch to
> Rose::DB::Object or DBIx::Class or (maybe there is some other out
> there??). I'm trying to understand what the differences are and which
> are relevant for my environment. So far, this is what I've picked up
> (yes a bit slim):
> 1. RDBO is faster.
> 2. DBIC has a Class::DBI compatibility layer that will make the
> transition from CDBI easier
RDBO is much faster on the perl side; in a majority of situations you
can generate SQL that's just as efficient on the database using DBIC
(certainly for selects, which in most apps is likely to be the majority
of the database load - although RDBO supports prefetching of multiple
one-many relations at once at the same level, which DBIC doesn't as yet).
However, RDBO achieves its perl speed by aggressive inlining of stuff
etc. - for example the main object retrieval function in RDBO's manager
class is >3000 lines in a single sub. DBIC values extensibility over a
few extra sub calls, so methods are much more broken out and there are
many more ways to hook into the DBIC execution process to extend.
DBIC also has the ResultSet concept baked into the design, which allows
complex queries to be built up piece by piece and allows a lot more
flexibility in terms of how you write your code. In addition, DBIC has
native support for use of GROUP BY and HAVING in resultset queries and
will be adding subselects, EXISTS etc. soon, whereas RDBO's philosophy
dictates that such things should be either a custom retrieval method or
In practice I'd say CDBICompat isn't actually that big a factor; it's a
moderately useful springboard but you'll find yourself wanting to
convert over to native use pretty fast anyway.
I wouldn't say either ORM is better than the other as such, more that
there are philosophical/design differences that lead to a difference in
feature sets and prioritisation of development work; your best bet is to
have a good look at both and use which one better suits your mindset
API-wise and/or better suits the constraints of your application
requirements and environment.
More information about the Dbix-class