Re: Efficiency vs. code bloat for SELECT wrappers

Sam Mason wrote:
> On Sun, Dec 16, 2007 at 06:31:56PM -0500, Colin Wetherbee wrote:
>> If I write one Perl sub for each operation on the table (e.g. one that
>> gets the username and password hash, another that gets the last name and
>> first name, etc.), there will be a whole lot of subs, each of which
>> performs one very specific task.
>>
>> If I write one larger Perl sub that grabs the whole row, and then I deal
>> with the contents of the row in Perl, ignoring columns as I please, it
>> will require fewer subs and, in turn, imply cleaner code.
>
> It sounds as though you're just treating the database as a relatively
> dumb datastore. They can be used as this, and Toms comments are as
> always good, but relational databases come into their own when you're
> writing more complex queries. When I'm writing my code I tend to put
> the SQL statements directly in with the rest of the code, abstracting
> away from the database tends to make things more complicated than they
> need to be.

Because I know Perl a whole lot better than SQL, PostgreSQL, and even
the Perl DBI, I'm always inclined to wrap the database stuff in a nice
little package and forget about it. This method has worked well for me
in the past, but the project I'm starting is much bigger in terms of
database use than anything else I've written.

You say you write SQL directly in your application code, rather than
writing task-oriented wrappers. I like that idea, but I can see that
getting really messy. What is your opinion on how it affects code
maintenance and things like that?

Thanks.

Colin