On Tue, Oct 05, 2004 at 10:56:14PM -0400, [EMAIL PROTECTED] wrote:Do you use Class::DBI to manage the database integration?
Actually, I'm so often working on many tables at once that I write the SQL myself (with help from my DBA... :-) and go for straight DBI. Often I'm having to use temporary tables and/or multiple joings to get at my data, so Class::DBI won't work. (The joy and bane of relational dbs is the relational element.)
At the cost of starting to sound like a Class::DBI evangelist,
And is that such a horrid price? :)
I think it's important to point out for those considering CDBI that using custom SQL does not necessary mean CDBI is ineffective. For me, one of the biggest sellers of the module was that all of my SQL statements could be stored in one place.
This is hugely imporant and is the sort of thing that a lot of FOSS projects miss. The difficulties in porting PHP apps from postgresql to mysql or the effective lack of bugzilla support for any database but mysql. I'm hopeful that Class::DBI will continue to be evangelized. Maypole has contributed to that considerably.
Just so as to not be a total flak** for Class::DBI I do miss the clean code I was able to produce using the little-advertised SQLayer. It made it very easy to say
%datastruct = $dbh->choosetransform($sql)
which doesn't win in the error handling department, but it made whipping up one-off data transformation scripts much less painful. Class::DBI is better in this regard than raw DBI, but its not up to the ease of SQLayer IMNSHO. Which relates nicely to your next point:
In fact, it's not even necessary to return CDBI objects; you could have your code return an array. I have a function called sql_hash which returns a list of hashes. I used to use this function for my select statements before switching to CDBI. It occasionally comes in handy when I have a complex join which I don't want to map to objects.
SQLayer provides a good example of the sets of transforms that people off want to do. All of these scenarios start with "given a sql query, give me:"
- the single column, single row result back as a single scalar
- a single columnt, multi row result back as an array of simple scalars
- a two column, multi row result back as a hash of the first column as the key and second column as the value
- a multi column multi row result back as a hash of hashes.
SQLayer does a few more, but those are the biggies.
Class::DBI can be extended to do this sort of thing, but having one consistant way of doing such things (such as provided by SQLayer) seems much easier to me.
I'm definitely NOT advocating SQLayer over Class::DBI here. For most cases I think Class::DBI wins over SQLayer or raw DBI. Using Class::DBI for medium to large projects leads me to wish I didn't have to merge in SQLayer-like functionality by hand as William describes doing. For small one-offs where there's no Class::DBI in place then using SQLayer (or something similar) is probably going to get the job done faster than Class::DBI or raw DBI at the expense of elegance and more difficulty in dealing with future feature creep.
OK, I'll be quiet now.
Don't clam up on us now!
** Avoiding flakishness during this season of maximal American flak-itude seems to be a particularly "good idea." :)
-- </chris>
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
--------------------------------------------------------------------- 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]
