I'd second the original question, I've always embedded the SQL (what's the
"S" for?) in the code, isn't that the point of the wonderful DBD::*
packages? As far as modularizing database calls, there are a couple
reasons I've had problems with that. I found the methods being rewritten
to handle about as many options as sql itself. (what if I want to sort
differently? what if I need a slightly different statement?). My solution
is to embed SQL most of the time, modularize basic calls (get_user,
get_group type stuff).
In addition, I'd like to rebut the original statement:
"not to mention the HTML embedded all throughout the perl (are they on
glue?)"
What's the alternative there? Embed perl in the HTML?
On Wed, 1 Aug 2001, Barry Hoggard wrote:
> I think a lot of people's approach, including mine, is to have OO Perl
> modules for all database access. In my code (I use Mason), a web page
> only gets its data through calls like this:
>
> my $obj = NAIC::User->(DBH=>$dbh, EMAIL=>'[EMAIL PROTECTED]');
> $obj->load;
> my $groups_list = $obj->groups();
>
> That way any needed SQL changes, or even ports to a new database,
> don't have to be done everywhere in my code.
>
>
>
> On Wed, Aug 01, 2001 at 10:12:45AM -0500, Joe Breeden wrote:
> > All,
> >
> > In his closing comments about UBB Kyle Dawkins made a statement that got me
> > wondering. He said "there's SQL embedded all throughout the Perl everywhere
> > (who does this?! oh my god, are they on crack?)".
>
> ...
>
> > It would be interesting to know how other people have solved that problem.
> > Currently, we are essentially using embedded SQL in our apps.
>
> --
> Barry Hoggard
>
>
