On Fri, May 9, 2008 at 8:31 PM, David Cantrell <[EMAIL PROTECTED]> wrote: > <delurk> hi, my name's Dave and I'm one of the London.pm cabal </> >
<delurk2> I'm Mark, and actually work in Bristol - though am familiar with many of this London.pm cabal through lurking on their list (though to be fair I was living in the smoke at the time) </delurk2> > On Fri, May 09, 2008 at 07:30:03PM +0100, Lyle wrote: > >> This last week I've overhauled a load of database routines grouping >> methods into easy to use objects. All the routines are currently MySQL >> based. My future plans are to have MSSQL, SQLite and maybe PostgreSQL as >> database options. >> >> My current experience is with MySQL only. Does anyone know of any good >> resources for doing this? > > Class::DBI or DBIx::Class. Personally I prefer Class::DBI but its > internals are nasty and DBIx::Class seems to have more active > development going on these days. They both provide a reasonably clean > objecty abstraction for databases so you won't need to worry about the > slight differences in syntax - although of course you are also largely > confined to functionality that they share in common. That means no > fancy tricks with triggers or stored procedures, although they both let > you define pseudo-triggers in perl - handy if you're using an old > version of MySQL, or need to do more in a trigger than SQLite can > support. > We've been using Class::DBI on our application for the last 4 years or so and it's a joy to write code without worrying about the underlying SQL. Some of the changes broke our (admittedly, rather specialised) app so we've stuck with Class::DBI::Frozen::301 from 2005. If I was starting again I'd take a serious look at DBIx::Class and Rose-DB as well. As Dave says, both are far more actively developed than Class::DBI . One thing I like about Class::DBI is the ability to easily fall back to raw DBI / SQL when necessary. Sometimes, creating hundreds of Perl objects from a big select isn't an option for performance reasons and bulk updates / inserts often need database specific calls. If database independence is a concern, then you might need to look at creating a package per database for any db specific queries that are needed for performance reasons. Mark. _______________________________________________ BristolBathPM mailing list [email protected] http://mailman.bristolbath.org/mailman/listinfo/bristolbathpm
