Re: Database module recommendations

[bobf]

Thanks to everyone for the helpful replies. Now that there are a good variety of responses I can start to get a feel for things.

My main goal was to get an idea of how more experienced monks would design a smallish address book-like application, specifically focussing on the choice of which module(s) to use, and why. My key questions were how much abstraction to use and where those layers needed to be.

To be honest, the responses surpised me a bit. I expected many different module recommendations, but I thought one or two would stand out. Based on the current replies, there does not seem to be a consensus for which modules people would select for a project like this. A few respondents advocated their favorite DB abstraction module, but an equal number said that those modules weren't powerful enough or that they simply wanted more control than those modules would provide.

I think I'll start by simply going with my initial gut instinct - to skip the DB abstraction layer and to create a set of functions that use plain DBI. I'll start exploring some of the modules that were recommended as I get time, but it sounds like abstraction layers aren't as universally used as I initially thought.

I also appreciate the comments regarding front ends. I took a brief look at the docs for some of the systems mentioned above, and I think I'm going to try my hand at CGI::Application (which has interested me for quite a while). A full web framework just seems too heavy for this app, and I'd like to get something up and running quickly (without a steep learning curve).

That said, I'd still very much like to hear additional opinions. :-)

[simonm]

For what it's worth, you may want to take a loook at my DBIx::SQLEngine, which supports multiple levels of abstraction, so you can start by using it as a convenience wrapper around common DBI calls, then move up to having it generate queries for you, and later add the object mapping layer if it seems appropriate.