>How different is say using the different PERL extensions, Perl::Oracle,
>Perl::SQL, than using DBI?
the DBI is designed to make your code work with any database back-end.
the modules include features and options which are specific to the database
in question.
there's a large helping of personal taste in the choice of which to use.
if you want to be able to migrate your code across several back-end
database engines, you'll probably want to use the DBI. then all you have
to worry about is finding a stable DBI extension for the engine you've
chosen..
if you know you plan to remain with a single engine for the life of the
code, or are simply willing to eat the labor cost of updating the code for
a new engine, the modules will probably be easier to use. each is closer
to the engine it supports, so you can pull all the funky (non-portable)
tricks the engine can do.
>Has anyone experienced the pros or cons of either when a backend may change
>depending on the application's needs such available resources -- system,
>monetary or otherwise?
i have two programmers beating their heads against the screens on that
exact issue right now. programming for the DBI takes work, and it's not
restricted to the code.. your table structures and relational logic have to
be pretty plain-vanilla if you want to migrate transparently from engine to
engine.
using the modules ties you to the engine. using the DBI with
engine-specific features ties you just as tightly. if you use the modules
with a great deal of discipline (and probably a layer of wrapper functions
to abstract the module-specific calls), you can write something which is
portable across multiple engines with limited effort. the same is
possible with somewhat less discipline using the DBI.
in all cases, i'd strongly reccommend that you look at *all* the engine
interfaces you think you might even possibly want to use in the future
before building the code.
in practice, we've had trouble finding current, stable DBI extensions for
the engines we've wanted to use, and all of them have had their own quirks.
you have to compile the DBI extensions directly into the perl interpreter,
which adds a whole family of compatability issues.
20/20 hindsight, i'd suggest using modules and a lot of careful thought.
>We're using Linux (most recent, stable build), PERL 5.004.x, PostgreSQL
>6.3, DBI 1.73. We also have NT servers that might be used similarly in the
>future.
our research has shown that PostgreSQL doesn't scale as well under high
load as MySQL. resource drain on the system increases more quickly for
PostgreSQL. if you expect your system to see a lot of load, you might
want to profile both engines against each other.
we've also looked at Sequel and Oracle engines as commercial alternatives.
we're currently using Sequel under RedHat because of other corporate
commitments, and my DBA keeps moaning that he wants Oracle.. of course, he
wants to add Oracle to the list of engines he's administered
professionally, so take that with a grain of salt.
mike stone <[EMAIL PROTECTED]> 'net geek..
been there, done that, have network, will travel.
____________________________________________________________________
--------------------------------------------------------------------
Join The Web Consultants Association : Register on our web site Now
Web Consultants Web Site : http://just4u.com/webconsultants
If you lose the instructions All subscription/unsubscribing can be done
directly from our website for all our lists.
---------------------------------------------------------------------
