Re: Efficiency vs. code bloat for SELECT wrappers

Ted Byers wrote:
> --- Colin Wetherbee <cww(at)denterprises(dot)org> wrote:
>
>> 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.
>>>>
> Right. First rule of software engineering is keep
> functions as small as possible, focussed on one thing
> wherever practicable. It doesn't matter if the
> language is Perl or C++ or Java, or a stored procedure
> in an RDBMS. One can always create additional driver
> functions that use the elemental simple functions to
> do more complex tasks (bearing in mind the
> complexities that will inevitably arise in multiple
> user situations).

I've programmed in this way for years, basically ever since I learned
object-oriented programming. I find it "cleaner" to keep functional
elements separate and access them sequentially from larger, more
broadly-focused functions.

>>>> 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.
> Define "cleaner code." The more data, and the more
> complex that data, the more code you have to write,
> regardless of whether that is in one function or
> several. Either way, done badly, can be a problem for
> both maintenance and performance.

See above.

> I routinely keep my SQL code distinct from my Perl,
> java or C++ code. When a client program needs to do
> something with the database, then either a child
> process executes a script I have written, if the
> client program doesn't need to do anything with data
> drawn from the database, or I have all the SQL code in
> one or more stored procedures, and use the appropriate
> client interface to invoke the stored procedure(s).
> Whether the SQL is in a specific script or in a stored
> procedure, my SQL code is kept distinct from the
> client code, regardles of the language I have used for
> that. I find this even MORE useful as my projects get
> bigger.

This seems like quite a departure from Sam's recommendation. Now, I'm torn!

Colin