On Mon, Dec 17, 2007 at 01:29:10PM -0500, Ted Byers wrote:
> 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.
Humm, this discussion is horribly domain specific. Abstractions are the
bread and butter of programming and designing them appropriately makes
the difference between things turning into a mess later on or not. The
only solid rules I stick to is that when I'm working to solve a problem
I've not solved before, I will get it (i.e. the way I go about solving
the problem, getting the right answer is generally pretty easy) wrong
the first time and probably only get it reasonable the third or fourth
time.
Luckily, big bits of software take a while to accumulate so it's
possible to do the naive thing first and then, when you know how things
work, better abstractions can be found and incorporated. For example,
I'd be tempted to replace your "get password hash" with a "verify
password" procedure that actually hashes the password client side and
then sends it over to the database for actual validation. However, you
may actually care what the password hash is, at which point the hashing
should be broken out and revealed to the appropriate balance of the
software.
> Each kind of abstraction has its place.
> It is up to the analyst or architect to figure out how
> many layers and what abstractions are appropriate for
> a given project.
Indeed. But to be able to choose a suitable set of abstractions, it
helps for the designer to know the ins and outs of the tools being
used. I was trying to encourage Colin to look at using databases
in a different way, different styles of programming suit different
applications and hiding the database can have detrimental effects as
well as positive effects.
Sam
