good chemistry is complicated, and a little bit messy -LW |
|
PerlMonks |
Re: To DBI or not to DBIby Ryszard (Priest) |
on Jan 29, 2003 at 06:56 UTC ( [id://230871]=note: print w/replies, xml ) | Need Help?? |
I use the DBI as a standard part of my web based applications, its damn cool.
Its easy to install, and with it, your web apps become that much more extensible. For example you now have access to any legacy data that you may need to, you can store all kinds of statistics that are accessable from within and out side of perl. Your sites become much more scalable (using a bunch of webservers behind a load balancer model), you now dont need to have storage on localhost. All of a sudden your web based data can be incredibly safe, now being maintained by a myriad of standard database backup/restore proceedures... There are prolly four main choices you'll entertain:
Oracle is expensive, but damn, its a great RDBMS. Postgres uses transactions and has support for subselects but isnt as popular as MySQL. MySQL seems to be the most popular among the web, but doesnt support subselects. Both Postgres and MySQL are free and both have DBI drivers (DBD). All are SQL92 compliant (an important factor in deciding which RDDMS you choose IMHO. Once you've decided you want to use a RDBMS lay our your requirements for what you want it to do, i'm thinking fault tolerance, support, cost, active development, availability, any specific features you're after, future requirements etc etc. After you've chosen your db engine and implemented it into your web app release, i'm sure you'll wonder how you ever did without one.. There is also (shamless plug) an abstraction to the DBI available. Update: This was my 300th post!
In Section
Seekers of Perl Wisdom
|
|