Thanks all for the input--I can't believe how much and how useful it was. I have started making a separate module with simple methods for performing queries that I will use often. I have a couple of larger objects stored in normalized tables, so I will probably try these as objects with methods to access the various pieces. I had thought about Class::DBI, but the overhead bothers me a bit as does the need to describe the table structure (which I am trying to get away from a bit, as it seems to be changing often).
If those are your only concerns about Class::DBI, then I think you should consider having another look. It took me a while to get used to Class::DBI, but it is a huge timesaver in development, and is so easy to use.
You concern about needing to describe the table structure is mostly unfounded, and is one of the reasons why you 'should' be using Class::DBI. There are modules for MySQL and PostgreSQL that will query the database for the column and primary key information and do 90% of the work for you. No need to hardcode the column info, as column names are pulled from the database for you. See the docs for Class::DBI::Mysql and Class::DBI::Pg modules for the set_up_table method. Just give it a table name, and presto, there is your Class::DBI table module.
package MyDB::Users
use base qw(Class::DBI::Pg);
__PACKAGE__->set_up_table('users');If that is still too much work for you, then look at Class::DBI::AutoLoader, which will create modules for each (or a subset) of the tables in your database at runtime. Here is the synopsis from the docs:
use Class::DBI::AutoLoader (
dsn => 'dbi:mysql:database',
username => 'username',
password => 'passw0rd',
options => { RaiseError => 1 },
tables => ['favorite_films','directors']
namespace => 'Films'
);my $film = Films::FavoriteFilms->retrieve(1); my $dir = Films::Directors->search( film => $film->id() );
The only thing you have left to do is defined the relationships between these tables and any other tables you have (has_many and has_a relationships).
As for performance. Many of the critisisms of Class::DBI in the area of performance are unfounded. All the queries that are performed by Class::DBI for retrieving data are based on Primary Key searches which are very fast. And complex joins can be supported very easily with a custom method in your table class. This allows you to do complex queries while still keeping your database access methods in a central location.
If you find after your project is complete that there is a bottle neck in a couple of queries that Class::DBI is handling, then optimize those instances. Don't discard the whole thing for a few edge cases though. Also, if performance in a CGI environment is important, then hardcode the table modules before you put the code into production if using the set_up_table method or Autoloader module I list above.
That being said, there will always be people that don't like the way Class::DBI does things. I just want to make sure that you 'dislike it' for the right reasons.
Cheers,
Cees
--------------------------------------------------------------------- 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]
