in reply to interfacing between perl and a database

One thing that was not mentioned in the answers you've already had, is that once you've implemented the DBI/DBD interface, it is normally very easy to change what underlying database engine your application will use. If you're able to avoid any database calls that are specific to a certain database and only use the 'smallest common denominator' you may be able to change the underlying database by changing one single line in your Perl code.

You will, of couse, OTOH have to install the new database engine, but that's out of scope for your Perl application. And this is exactly my point. Using DBI/DBD, and taking care not to call any 'obscure' database functionality, you may make your application almost 100% unaware of what database you're using.

Which is a Good Thing (TM used with permission).

f--k the world!!!!
/dev/world has reached maximal mount count, check forced.

  • Comment on Re: interfacing between perl and a database

Replies are listed 'Best First'.
Re: Re: interfacing between perl and a database
by data64 (Chaplain) on Nov 12, 2001 at 04:06 UTC

    Good point biker.

    You can actually start out using DBD::CSV which actually uses text files and then move onto a real database file. That would allow you to focus on learning just the DBI/DBD part of the piece and then when you are comfortable with it, move on to putting in a real database.

    Disclaimer: This is in theory, ie. this is how it should work. Never tried it so am not sure if there are any practical problems involved. Would someone who has attempted something similar please speak up.

      THanx guys, its been steam ahead with mysql all week and im finally there - atlast, a proper database.
      THanx guys, its been full steam ahead with mysql all week and im finally there - atlast, a proper database.