[geeks] Databases

[joshua d boyd]

On Sun, Aug 26, 2001 at 10:48:17PM -0400, Ken Hansen wrote:
> So, to rephrase it - it seems that it is a way to implement on the database
> server logic that can not be implemented in SQL...
> 
> Interesting, but not great, in my opinon - SQL is *very* flexible, and
> almost any query should be able to be appropriately refined if done
> properly.

Well, technically stored procedures are SQL, usually.  When I've used
stored procedures, cursors where often involved.  Yuck.  That is when even
perl for stored procedures starts sounding nice, but then you wonder if
stored procedures where really the best idea to begin with.
 
> What I really hear in your example Josh, is that it is a way to implement a
> three-tier application, with only two physical tiers...

Actually, that is a fairly good assesment.  I wasn't thinking of this when
I wrote the first message, but on one project (a web site), selects where
done normally, but all database updates where done using stored
procedures and that was a lot of the business logic.

I would have rather used a 3 tier architecture, but it had to be an MS
project, and to do MTS or custom binaries on MS means having to colocate
(because of the vulnerability to bad exes), which was out of the budget.

Why didn't we do the middle business logic as a set of VBScript
classes?  I don't quite remeber the specifics, but that was what was felt
closest to right in the circustance.  We did start out trying to write
the business logic as classes in VBScript.  

This project was for a friends small startup web dev company.  I was
supposed to just help, but ended up doing pretty much everything but
dealing with the customer on that project.  I really wish that we could
have gone with colocation, but it just wasn't possible.
 
> Thanks for the insight, I never get involved with this stuff...

It pays the bills.  There are parts that I actually might enjoy under
other circumstances, but the projects where I've used these tools were
usually ones I didn't really care for.

-- 
Joshua D. Boyd