jdtoronto has asked for the wisdom of the Perl Monks concerning the following question:

Esteemed monks,

I am confused. I have been programming in Perl on and off for about 7 years. I am not a programmer by training, but an engineer and mathematician. But now people pay me too much to help with computer problems so I do that instead!

I use DBI regularly, usually with MySQL. Lately I have been reading all the various writeups I see here in the Monastery referring to various wrappers to the DBI interface. They sound great - but I think most of what has been written about them is adversarial - somebody promoting their faviourite wrapper or the one they wrote.

Having read the wonderful offering from gmax on the DBI and the chromatic paper on perl.com I now hunger for more light.

Can any of you point me to an unbiased summary of the pro's and con's of the various wrapper modules? Alternatively I would be eternally grateful if someone would care to put fingers to keyboard and write one.

...john jdtoronto

Replies are listed 'Best First'.
Re: DBI and wrappers etc confusion.
by perrin (Chancellor) on Aug 18, 2003 at 20:11 UTC
    They mostly fall into two camps: tools to make simple DBI actions simpler, at the expense of performance, or tools to map between objects and database tables. I gave a talk on the latter at OSCON this year, and am working on turning it into an article for publication. I can't say much about the whole "Easy DBI" world since I've never had any need for it.

    Is there something specific that you want help with here, or are you just wondering if there's a Better Way out there?

      Perrin,

      I look forward to seeing your paper!

      In particular I find I am doing the same things over and over again. I keep thinking, wouldn't it be cool if I could easily relate this 'hash' or this 'array of hashes' to a DB table.

      Just recently I have seen some quite specific modules, such as hash2table and table2hash, they look fine, as far as they go, but I think I am looking for some greater level of abstraction. For example the ability to easily manage complex data-structures, for storing the state of a complex state machine, or for storing configuration hashes or arrays which might be quite variable in nature. In one application I have mappings of fields in an import file realting them to a database table. It is two arrays, now, how about an easy interface to save an array of arrays in a named structure and save them in the db. Of course, the arrays are both the same size, but they could be as small as 2 values each or as many as 40 to 50. I just want them back the same way I had them before.

      I know I can do some of this using a CONFIG module, but I am hoping that I don't have to write some sort of kludge around a CONFIG module when a DBI wrapper of some sort might be easier to handle and more usable for me.

      Make sense?

      jdtoronto

        You could look at Tie::DBI. I don't know much about the rest of the "easy DBI" modules.
      They mostly fall into two camps: tools to make simple DBI actions simpler, at the expense of performance
      Of course, the exception to this largely true generalization would be PApp::SQL which is coded in XS for speed, but is a snap to use as well.

      Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality

Re: DBI and wrappers etc confusion.
by waswas-fng (Curate) on Aug 18, 2003 at 20:57 UTC
    Good luck with responces here, as you have noted before -- almost all of the DBI posts are biased in one form or another. People will be biased about these types of things (heh look at the mysql/postgres posts). Just tkae the posts with a grain of salt -- just because they are biased twords the posters history and feelings does not mean they are not full of real data that can be useful. If you search on cpan DBI you will find many modules that have many people that consider them useful. Take a look at them yourself, see if any fit with your idealisms and try them out. Look for ones that are updated and current -- those will be some of the most widly used. Other than that any posts you get from this question are going to be as biased (if not more because the biases are going to be hidden) as any posts you see on super search. just my .02 $

    -Waswas
      Waswas

      An excellent suggestion. I have searched what I can find on perl.com, perlmonks and a few other places. But a good solid review of the various modules may be my own task!

      This is what I was hoping to avoid, but it seems that laziness may not pay off i nthis case.

      John jdtoronto

Re: DBI and wrappers etc confusion.
by Juerd (Abbot) on Aug 19, 2003 at 08:48 UTC

    Wrappers are there to keep your code clean and readable at the expense of performance. In general, the more the wrapper abstracts, the less efficient it is.

    Sometimes you need extreme performance, and in that case raw DBI is the best solution.

    Wrappers are simplified interfaces. That means that if you use a wrapper, some things may not be possible. But the things that are possible, will be much easier and require less code.

    I made DBIx::Simple for people who don't mind cluttering their code with SQL queries. It can't be as fast as raw DBI, but it is much easier to use.

    If you don't mind a huge performance hit, and you want to keep your code extremely clean, try Class::DBI. I've used it in several projects and really love it. Unfortunately, something that abstracts as much as this does, cannot be made much faster than it is.

    Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      Thanks Juerd,

      DBIx::Simple is one I have installed to have a play with and the same with DBI::Class.

      Your remarks about performance are noted. I have one programme that work with a database of around 2 million records, Perl/DBI/MySQL is vastly faster than the MS-Access/VBA application it has replaced, but when I tried a version using some of the wrappers (I didn't record which gave what performance, just notes of preference) the performance sometimes took a hit of a factor of 3 to 10.

      But I have a lot more playing to do yet!

      jdtoronto