And frankly, I love it!
Why? Convenience and ease-of-use. It's much easier (and more enjoyable!) for me to write a few lines of code to create a class based upon a table in my database than it is to write a piece of SQL that updates the same table, deletes from it, inserts rows into it, etc. . . . Class::DBI does it all for me. It's made me more productive and has led to cleaner-looking and more maintainable code (IMHO). I spend less time writing code for database maintenance, and more code for actual program logic. And that is the fun part!
It doesn't hold up for some things. Some of the queries we allow for in our applications aren't well suited to what search capabilities exist in Class::DBI, and we're probably too lazy to figure out how to remedy that ;) But we can still reap some advantages from Class::DBI. We often stash search results in a temp table, and after using SQL to populate the result table, Class::DBI makes it easy to access those results.
Give it another shot. Dive in and write an app with it. I really think it may change your mind.
Good luck! Jason
[EMAIL PROTECTED] wrote:
I have been playing around with Class::DBI to see why everyone loves it so much and I cannot figure it out. You have to set up your own database and tables. Then you have to tell the class about your table and it's structure. Then, you have to learn the class's new syntax for dealing with a relational database which is less flexible than the SQL which you must already know since you had to set up your own table in the first place!
The only benefit I can see is that you can move your code to different databases without change, but I would prefer a solution that abstracts the database interaction completely where you can design forms and modify them and the database will shape itself to fit the forms.
As far as telling Class::DBI about the database structure, I don't understand why. It seems fairly easy with DBI functions to have a program read database structure itself.
Here is a script that reads the entire structure of all of my databases:
#!/usr/bin/perl
use warnings;
use strict;
use DBI;
my $dbh = DBI->connect ("DBI:mysql:host=localhost;database=mysql", "", "",
{PrintError => 0, RaiseError => 1});
my $dblist = $dbh->selectcol_arrayref("show databases");
my %databases;
for(@$dblist)
{
$dbh->do("use $_");
my $tables = $dbh->selectcol_arrayref("show tables");
my @full_table_data;
for (@$tables) { my $columns = $dbh->selectcol_arrayref ("describe $_"); push @full_table_data, [ ($_, @$columns) ]; } $databases{$_} = [ @full_table_data ]; } use Data::Dumper; print Dumper(%databases);
I am not putting down the module. It's just that if so many professionals feel that it is a good tool, I just wanted to understand why.
Thank you, Mark
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[email protected]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[email protected]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
