[Gllug] A programming question. long.

[Bruce Richardson]

On Sun, Jul 08, 2001 at 03:16:06PM +0100, Alex Hudson wrote:
> >On what grounds is it a bad habit?
> 
> On the grounds that the database is not aware of the context in which a
> transaction happens; it is just a filestore.

Not if you put the business logic in there, it isn't.  Your's is a
circular argument.

> On the grounds that such as
> design does not scale.

So you keep saying but without any evidence.

> >On the contrary, putting the logic into the database increases the load
> >on the server.
> 
> I didn't say it made the database faster (although in some cases it would),
> it makes the system perform better. If you want a sorted result, for
> example, you don't have the result set returned to you and sort it yourself,
> you ask the db to do it - it's faster. If you want to see rows which aren't
> being 'dealt with' (in your example), you use a where clause, you don't have
> the whole set returned to you. Etcetera.

Which has absolutely nothing to do with business logic.

> >The database should enforce credit limit rules - if it doesn't then any
> buggy application
> >(or fraudulent access) may be able to steal credit.
> 
> I don't agree with this at all. Your argument is a web-of-trust based
> argument

Bollocks!  Absolute bollocks.  I don't know whose e-mail you were
reading but it wasn't mine.  That is 180% the opposite of what I have
been saying the whole time - as you would have seen if you had bothered
to read or answer the banking example.  How can it be blind trust if the
database requires the application to authenticate?  In all my examples I
explicitly stated that the database would use user-based security and
authenticate both the application and the user.  You have absolutely
no justification at all for saying:

> A database needs to trust applications, true, but
> that trust doesn't need to be blind, which is where your security argument
> falls down.

I gave a specific example - the banking application - demonstrating how
putting business logic into the database increases security.  I also
gave a genuine real-world example of where some banks did put business
logic into the application with disastrous results.  All you do is
ignore it.

Your model is the one built on blind trust - you trust every instance of
every application to do only what it should and you trust the
application to authenticate.  That is an approach which doesn't scale.
It may work on one site with a simple network but not on anything
larger.

> 
> A simplistic example: how does the database tell the difference between a
> transfer of funds between account A and account B, and separate debit of
> account A and credit (of equal value) of account B? Answer is there is none,
> only the application (which is dealing with the meta-data also; in this case
> the context of the transaction) is aware

Asked and answered, I gave several examples of how the database can
provide the context.

>. Of course, in this case, it is
> possible to generate a stored procedure to deal with transfers, and another
> to deal with debits, another to deal with credits, etc., but this is only
> possible due to the simplistic case set out here, and is also another
> example of moving application into the database - there are many (more
> complicated) examples where it is impossible to the db to distinguish
> context, and as such, it has to be the application which deals with the
> logic.
> 
> Putting business logic in the database only works for simple systems - once
> you have something even vaguely complex, it all falls down because you need
> to generate ever-higher level functionality within the database - at which
> point, the database becomes an application server and you are back to the
> old client-server model which is so far past it's sell-by date it's untrue.

This reads as if you're rehearsing somebody's lecture notes.  I don't
accept your hypothesis - which is all it is without concrete examples -
and I certainly don't accept this:

> Designs like that don't scale

It scales a lot better than re-writing the same functions multiple times
and blindly trusting each application to behave properly.

Business logic tends to be much simpler than the applications which
present or implement it.  The database server is also a simpler
environment than the application.  Development and maintenance of the
business logic is much simpler in that environment.

Putting the business logic into the server does not make it an
application server, either.  The database is not dictating the contents
of data entry forms, the order in which questions or choices are put to
the user etc.

> 
> And this is exactly why I think it is a bad habit. The design doesn't scale,
> the security model doesn't scale (your web of trust relies on having only
> one participant)

Again, I don't know whose e-mails you have been reading but they aren't
mine.

> , which means this is only suitable for small-scale simple
> solutions. I also hesitate to think how a database being controlled by procs
> and triggers would be replicated in a valid state, because that is also
> non-trivial.

Only because you constantly ignore my repeated demonstrations of how
stored procedures and triggers can be made specific to the client, the
application and the user.

> 
> Applications should control the business logic of data, and use transactions
> to transit the database between valid states. Stored procedures, triggers,
> et. al are all hacks to generate the performance necessary of a real-world
> system - they are not strictly necessary, but like denormalisation, we swap
> the perfections of design for real-world speed.

On the contrary, triggers and procudures et. al. are only possible on
larger scale systems where the database server has the capabilities and
and the capacity.  But where these are available, writing the basic
data-handling routines into the application is no more sensible than
having it do low-level disk writes.

It's small-scale applications where enforcing a data/application
interface affects the design-load: it requires extra discipline from a
design team of one or two.  But any large application will have a team
specifically responsible for the data interface, other developers having
to work with their API and not going to the data directly.  If some of
those team members are database developers rather than application
coders this has precisely zero implications for the work of the
development project as a whole.

-- 
Bruce

The ice-caps are melting, tra-la-la-la.  All the world is drowning,
tra-la-la-la-la.  -- Tiny Tim.
-------------- 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/20010708/020efb79/attachment.pgp>