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.

Database Abstractions 4 Comments More | Login | Reply /

 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.

    • Dang. I seemed a bit crabby in that, didn't I? I think I made the situation sound worse than it really is.

      • I don't think that was overly crabby. It just highlights that there's a solution to this problem that is simple, obvious and wrong.

        I haven't used Class::DBI in very many projects, but it does make the process of writing an abstraction for a simple database downright painless. I've also written a couple of thin database frameworks, so I've got an idea of what the problem domain is about.

        The situation you described feels like a heavyweight OODB mapping. I don't think that's an accurate description

        • Well, one thing that might help is to implement a "one table" interface. Imagine that your boss wants a report of the average sales per salesperson. If everything was in one big table, you could write:

          SELECT   salesman_name, avg(revenue)
          FROM     the_table
          GROUP BY salesman_name
          ORDER BY salesman_name

          Of course, such a database would be impossible to manage, but if you treat it like that, you can drop the FROM clause:

          SELECT   salesman_name, avg(revenue)
          GROUP BY salesman_name
          ORDER BY salesman_name

          Which can be translated into Perl as:

          my $report = Report->new(
              [qw/salesman_name avg(revenue)/], # desired fields
              [qw/salesman_name/],              # group by
              [qw/salesman_name/]               # order by
          );

          And, in reality, that's very close to what we do at work (we also pass in a request object that checks permissions and alters the SQL appropriately.) Something like this could potentially be made to work with CDBI because each class, when properly designed, lists how it links to other classes and the joins would be built off of that. If we grab the data from the classes, we could build a system like that. This is not pie-in-the-sky because we've done it where I work, but the code is proprietary. I've been given permission to reimplement it, though, and I think CDBI would be perfect for this. I think it could reduce the amount of arbitrary SQL that gets written. I just need to get off my tail and write this :)

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.