=pod
L, you
L
about L performance.
Even without benchmarking you could have
L,
that Class::DBI is quite slow. Fortunately there are some alternative
object-relational mappers available in the perl universe. The best ones I found
so far are
L and
L. I took a closer
look at both and would like to share my experience.
As L shows,
RDBO is faster than DBIC in most of the case. The generated SQL doesn't differ
too much and therefor it must be the perl side of things that makes the
difference.
Matt S Trout says:
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.
Also its idea of resultsets is something I really love. Here's a small example to illustrate that:
lang:Perl
my $user_rs = $schema->resultset('User')->search({ registered => 1 });
$user_rs = $user_rs->search(
{ comment.title => 'Foo' },
{
join => { 'article' => 'comment' },
order_by => 'user.name',
},
);
# no sql executed yet.
# now you can use your resultset as an iterator or query a list
# of User objects from it or ..
while (my $user = $user_rs->next) {
...
}
# or
my $count = $user_rs->count;
Using these resultset makes it extremely easy to built up queries piece by
piece and to work together well with, for example, a templating system. You
don't need to fetch all row-objects and give them to your template. You can
just pass the iterator to the template library.
There's a lot more to say about this two object-relational mappers (for example
RDBO supports prefetching of multiple one-to-many at once, which DBIC doesn't),
but maybe you just should take a look yourself. I personally prefer DBIx::Class
for its vast extensibility.
=cut