[Gllug] A programming question. long.

[Alex Hudson]

On Sun, Jul 08, 2001 at 05:37:29PM +0100, Bruce Richardson wrote:
> > 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.

Yes, it's almost a reductio ad absurdum on the fact that you claim your db
with business logic is neither filestore nor application server :)

> > On the grounds that such as design does not scale.
> So you keep saying but without any evidence.

Er, I did. Read on....

> > >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. 
> Which has absolutely nothing to do with business logic.

We weren't arguing about business logic here; we were arguing about
performance. I said putting stored procs on the database can lead to better
performance (which I also stated was the raison d'etre of stored procs), you
said it didn't because the database would be slower. Which wasn't addressing
the point.

> > I don't agree with this at all. Your argument is a web-of-trust based
> > argument
> 
> Bollocks!

No, it wasn't, because:

> to read or answer the banking example.  How can it be blind trust if the
> database requires the application to authenticate? 

Where did I say it was blind trust? Answer: I didn't. Perhaps your
definition of web-of-trust is different to mine?

> 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.

Yes, I do. My point was precisely this: 

Your world: database has a web of trust which includes only itself.
Applications are not trusted. (The statement I made above wasn't in
reference to your design, btw).

My world: the database has a web of trust which includes itself and
applications. Note it does not follow that I allow any application to
perform any operation. (This was what I was talking about).

The point was that in my world (either world, in fact), blind trust isn't
required - the size of the web of trust is a security non-issue, and hence
your argument that extending the web of trust only to the bounds of the db
increases security is false.

> I gave a specific example - the banking application - demonstrating how
> putting business logic into the database increases security. 

And I denied it by saying that the web of security is extensible beyond the
bounds of the database. You can't argue that the only way to secure a
database is to have it trust nothing; that doesn't make any sense and there
are countless real-world examples which show that to be utterly false. You
can't build large systems from only one member.

> 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.

No; you gave an example of where the web of trust was broken. Different
argument. I can break your web of trust by finding exploits in the database
or the implementation. That's an implementation security issue, not a design
one - and we're arguing about design here.

> Your model is the one built on blind trust

No, it definitely isn't. Yes, I trust applications. No, that doesn't mean I
trust them blindly - that doesn't follow. A web of trust is composed of a
scheme of authentication, a set of priviledges (mandatory or otherwise), and
a set of users who have those priviledges. I don't see blind trust mentioned
anywhere in there.

> That is an approach which doesn't scale. It may work on one site with a
> simple network but not on anything larger.

Rubbish. Three-tier architecture is one of the most common around - multiple
application servers with multiple views of one or more common data store on
one or more database servers. I don't see any large database implementations
consisting of client applications directly querying one database via
mock-rpc.

> > A simplistic example: how does the database tell the difference between a
> > transfer of funds between account A and account B
> 
> Asked and answered, I gave several examples of how the database can
> provide the context.

It was a rhetorical question to show that such design requires ever-higher
level functionality built into the database. The database cannot provide the
context though; it must have the context communicated to it - the point is
it doesn't know itself, and cannot, since that is provided by the user.

> > 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.

No, it doesn't. You're stuck with one database system. That doesn't
integrate with other systems, and doesn't extend its web of trust. It
doesn't fit three-tier architecture. It is a little island of data,
completely cut off from any other system, which makes it hard to distribute,
hard to make resilient. It is secure, yes, I'm not arguing that - I am
arguing that it is not the only method to make a system secure.

> 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.

It does make it an application server in the sense that to access the data
multiple high-level functions are required. The more logic, the more
high-level functions, and the more high level they become, more and more
abstract from the actual data. It doesn't have to have a GUI to be an app
server.

> > 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.

Excuse me, you said your database trusts no-one. Therefore, your web of
trust has only one participant. To restrict yourself to a system with one
member is inherently unscalable. I don't see how you can argue with that?
Unless you're arguing your database does trust others?

> > Stored procedures, triggers, et. al are all hacks to generate the
> > performance necessary of a real-world system
> 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.

The fact that they are only available on real db products does not
contradict the fact that they are a performance hack...

It comes down to this: you said your design improves security. I do not
argue your design is insecure, I argue it is not the only secure model. Your
model simplifies security, I don't accept it improves it by design. You also
said your design improves scalability - I don't accept this because your
model is based on one central system, whereas the accepted criteria for
scalability is that extra parts added to a system equates to a linear
increase in performance (i.e., bucking the law of diminishing returns as far
as possible). It becomes difficult for you to balance load across systems
because your web of trust does not allow it, for the same reason it is also
difficult to interact with other systems.

Cheers,

Alex.

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug