>
> I think taking this appoach (updating thru strored procs) is a 'poor mans'
> multi-tier
> I would either
>
> 1/ Put in a middleware layer or
> 2/ Implement update multiple tables, validity checks et al in triggers
>
> Do you really want to implement a complex middle layer in a script
language?
> The trigger approach will enforce consistency of update, moving your
updates
> to
> stored procs just splits the logic, doubles the bugs and makes your app
less
> portable
Interesting, I hadn't thought of it that way. However I disagree with some
of your conclusions. You are right that using stored procs to implement more
complex updates etc is a cheap alternative to a middle layer. I also agree
that the functionality provided by stored procedures is much more limited
than most middleware. However that doesn't mean it isn't a valid way of
approaching the problem. If you would like a little more control over how
your database is updated but you don't need a sophisticated object layer,
load balancing, portability or any of the other features middleware excels
at, then stored procedures alone can be very useful. I would argue that they
are much less complex and therefore cheaper for a smallish project/IT team.
In order to do middleware well I believe you have to do it very well - there
is no point in slapping together a middle layer quickly because it will
cause more problems than it solves. Whereas medium complexity stored
procedures are fairly easy to write, surprisingly easy to debug and provide
other advantages such as security (only sa has direct update priviliges to
any of the tables).
I'm also not sold on triggers. Maybe I've just never seen a good
implementation, but in my experience they tend to cause performance problems
and are vastly more difficult to debug than stored procedures. One of their
biggest benefits is consistency of updates, but if you have a readonly
database which only your carefully written stored procs can update then you
have consistency of updates anyway.
Note that I'm not saying Stored Procedures are good, middleware is bad. Far
from it. I'm merely saying that in the right situations stored procedures
can provide a effective and comparitively cheap alternative to middleware.
David.
DB Solutions Ltd.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
