Ted Byers wrote:
--- Colin Wetherbee <cww@xxxxxxxxxxxxxxxx> 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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
