[Dbix-class] DBIx::Class or Rose::DB::Object or other???

[Matt S Trout]

Kurt Hansen wrote:
> Hello,
> 
> 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 
> page:
> http://rose.sourceforge.net/wiki/index.php/RDBO/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 
a view.

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.