One of the mysteries of Perl to me is that why, as of yet, is there no UTF-8 support in DBD::mysql although this issue has been discussed on the msql-mysql-modules list since at least 2003 (using the MARC archives). This is also given that MySQL does have UTF-8 support itself.Read more...
On this page
IMO, one of the major limitations of Ruby on Rails compared to other frameworks is its ORM, ActiveRecord. ActiveRecord is a fairly early ORM (object-relational mapper) that has made some questionable design decisions and doesn't support some very basic relational database concepts. These issues have been discussed on Joel on Software and elsewhere. Here are some limitations I wish were fixed:Read more...
In the area of Perl ORM (object relational mappers), there are essentially three players: Class::DBI, DBIx::Class and Rose::DB::Object. Of the three, Rose::DB::Object (a.k.a. RDBO) is known to be the fastest, running just 2-4 times the speed of straight DBI in many tests (albeit using an unloaded database). DBIx::Class is known as the most extensible and flexible. Class::DBI is considered outdated (e.g. it doesn't support JOINs) and to be avoided by many. RDBO is the fastest because speed is it's primary design consideration, implementing many perl and DBI-level optimizations. The design philosophy is described as:
Basically, any work that can be done "up-front" (or at least "infrequently") is done in order to keep the frequently used runtime code path very tight. - John Siracusa
RDBO's implementation accomplishes this feat in several ways:
- aggressive code inlining: method calls can be very expensive and RDBO goes to great lenghts to avoid this. The get_objects method in Rose::DB::Object:Manager is 2129 lines long.
- extensive caching of "derived metadata", e.g. commonly used SQL query strings, column lists, etc.
- extensive use of "the 'fast path' in DBI, such as always using bind_col() and fetch() to retrieve data instead of fetchrow_array(), unbound calls to fetchrow_arrayref(), or fetchrow_hashref()."
- "compiling down" accessor and mutator methods, both with and without triggers, to an optimized form in order to shorten the code path.
Achieving this high performance has resulted in some compromises. They include:
- the code is harder to maintain and extend, resulting in a smaller community of contributors.
- aggregate functions and other queries that do not return table rows (e.g. GROUP BY, HAVING, etc.) are not natively supported yet. A previous entry, Rose::DB::Object - aggregates, describes how to implement aggregates with RDBO.
Perl has a TIMTOWTDI tradition and ORMs are no exception. The primary alternative, DBIx::Class, is designed with extensibility as it's primary consideration and addresses the compromises RDBO has made. The implementation gives up some perl execution speed to RDBO to gain this extensibility while generating roughly equivalent SQL for a similar database load. Both RDBO and DBIC are much faster than Class::DBI. The extensibility philosophy has resulted in an alternative ORM that is more flexible, supports aggregate functions and has a larger community of committers relative to RDBO.
RDBO should be a strong contender if you want the fastest Perl ORM and can accept the design decisions it has made to achieve that performance. If you would like some extra capability and can give up some perl execution speed in your web nodes, it may be worthwhile to evaluate some alternatives.
One of the advantages DBIx::Class has over Rose::DB::Object (RDBO) is that it natively handles GROUP BY, HAVING, etc. I use GROUP BY a lot so I asked John Siracusa how to do aggregate functions such as count and sum using GROUP BY with RDBO.
RDBO doesn't have native support for aggregates because it's designed to return row objects and the results of aggregate functions are not rows in any table. In the future RDBO may have a built-in get_results() Manager method that returns "data" instead of row objects, but for now there are two alternatives (quotes by Siracusa):
- Manager methods: "the RDBO way to do queries that have aggregates is to create a manager method that runs the desired query and returns the results. you can use the RDBO query builder to constrict the SQL if you want, the where part, for example"
- Views: "the other way is to make a view and have RDBO front that view as if it were a table letting the db do the aggregating part under the covers [...] big aggregate queries tend to be slow vs. a good view in a database that supports them well"