[Gllug] A programming question. long.

[Bruce Richardson]

On Sat, Jul 07, 2001 at 06:51:20PM +0100, Alex Hudson wrote:
> >Code is code is code.  If the server-side programming language can
> >implement a function, why is that invalid?
> 
> It's not 'invalid', it's just a bad habit to put business logic in a
> database.

On what grounds is it a bad habit?  I gave plenty of examples of how it
can reduce errors and enhance security (not to mention hugely reducing
the administrative load)?  And if views (and user security) are used
then it doesn't place any restrictions either on priveleged
administrative processes or on any future applications.  All it requires
is co-operation between designers.

> The only excuse you can have is to use import application into the
> db server (stored procedures, triggers, etc.) for performance reasons, much
> like denormalisation. But it should be avoided where possible.

On the contrary, putting the logic into the database increases the load
on the server.  Each stored procedure and trigger slows the response
time for any query which activates them.  If performance is crucial,
that may be a reason to move functions (and the corresponding load) to
the client.  Unless you have a very feeble client machine, of course, in
which case you have no choice but to keep the logic on the server.

> That wasn't my point - my point was a database cannot validate meta-data,
> hence business logic belongs in the application. It _is_ up to the database
> to validate the data to the design; it _may_ be up to the database for basic
> validation according to business logic if performance demands; however, the
> final say is always for the application.

This assumes the database is designed in ignorance of the uses to which
it will be put.  I've no problem with the application adding extra logic
but the database enforces the essential limits.  Returning to the
banking example: when a credit transfer or withdrawal is made it's up to
the application how it authenticates the user, what questions it asks
etc but it makes no sense at all for the teller application to be the
place where the overdraft limit is enforced.  The database should
enforce credit limit rules - if it doesn't then any buggy application
(or fraudulent access) may be able to steal credit.  

If the application enforces the credit limit as well - i.e. it refuses
to process transers/withdrawals which it deems to break the rules - then
that doesn't expose the accounts database to any extra risk.  But it
does add the burden of updating all the applications, wherever they are
installed, whenever the credit rules are changed.  If the bank
introduces special credit rules for special customers, it either has to
wait until all the applications have been updated in all branches or go
back to paper and pencil for those customers in the meantime.

If the application is the only place where the credit limit is enforced
then for the duration of the upgrade different applications will be
doing different things with the data.

Imagine this were an ATM application?  Doesn't that show how illogical
it would be to have the credit rules - the business logic - in the
application?  The ATM should not in any circumstances be deciding
whether you can make a withdrawal or not - it should simply request the
withdrawal and report the result.  In the early days of ATMs, some
designs did have the ATM making the decisions and fraudsters made a lot
of money out of it.  That security hole was closed asap.

Credit rules should be in the database.  It guarantees security and
means that rules can be updated a) with instant effect and b) without
having to update any applications.

You keep on saying that this is wrong, a bad habit and to be avoided but
you haven't given a single reason why or refuted - or even addressed -
any of my arguments to the contrary.  If you keep on saying it's wrong
I'll keep asking why until you demonstrate why.

-- 
Bruce

Remember you're a Womble.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 261 bytes
Desc: not available
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20010707/4703bc85/attachment.pgp>