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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
