Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The benefits of database abstractions such as Class::DBI are obvious, but the downsides of these technologies can hamper scalability. On one hand, with the CDBI approach, we have a clear mapping of classes to tables, but the databases for which these have been designed are relational when classes tend to be heirarchical. This not only forces developers to accept awkward design constraints (subclassing a table can be an act of supreme masochism), but with the wrong design, it can also limit scalability.

    • AFAIK, Tangram can't help you with this, nor can any other abstraction layer. Things that try, like Hibernate, just end up making you write your query in their query language rather than SQL. I prefer to use SQL for that.

      I think people who try to use Class::DBI and friends to isolate them from SQL are chasing the wrong goal. I don't need isolation from SQL -- SQL is easy and works great! All I want is for the busywork code that does all the obvious work to be automated for me, which is what Class::DBI is good at.

      In your hypothetical situation, writing the custom query is a big win, because Class::DBI will do all the DBI stuff for you, move the data in and out objects for you, allow you to wrap up the whole thing in a single method like Region->customers().