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 16 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.

    • I'm sure object-oriented databases are (at least in some design cases) worth looking at. Too bad there is no (to my knowledge) good OSS implementation of an OODMBS.

    • 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 salesma

    • 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

    • > As systems get larger, we start needing more and
      > more ad hoc queries. Writing custom SQL for each
      > one becomes problematic

      Why is this problematic? If you have to write non-trivial queries to get information out of a database, how else would you expect to be able to do that?

      This isn't meant to be a snippy response - I'm truly interested in what other sorts of ways this sort of thing could be done.

      Tony
  • This hasn't gone unnoticed elsewhere. I had dinner with a Java guy at OSCON and he said "I popped my head in on a few Perl talks, but they're very boring. They're discovering all the stuff that Java had years ago, and everyone's reimplementing it in a different way."

    --Nat

    • That knife cuts both ways. Java 1.5 is getting generics, which have been around since perl1. And don't get me started on inner classes. ;-)

    • Ask 'im about regexes. And tell 'em that we don't need no stinkin' autoboxing because we don't do that silly "primitives in an OO world" mess :)

    • What he doesn't realize is that Perl has had them just as long. Tangram has been around for several years. What he is picking up on though is that Perl developers have traditionally been very skeptical about frameworks and abstractions like this, while Java developers embrace them. Java has paid for it too, with the resounding failure known as EJB. It was so bad that the upcoming EJB 3 spec basically scraps the old stuff in favor of a model copied from the (fairly recent) open source tool Hibernate. Hi

    • I like to think of JCP as a herd of elephant real estate speculators staking out claims in the ever-expanding frontier of The Core Libraries. No other image really captures the elegance, precision, simplicity, and unashamed piles of excreta in their wake.

      For fun, go to the JavaOne exhibit hall, yell out "I have a new API for controlling coconut-throwing monkeys", step back, and enjoy the stampede. If the 18-month standardization process doesn't produce a library that includes some sort of rocketry, I'll

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