Re: Multiple specification of constraints

>
> No such constraint exists. All you have to do to disprove my contention is
> demonstrate a single constraint in a well designed schema that contradicts
> my assertion.
>

1. (Data outside the one database).
If the constraint is over more than one database, there is not ONE database that can check the constraint. If a link is not possible the constraint has to be checked outside the database.

2. (Security is kept outside the database.) Bank, black box identity checking, is done outside the database for several reasons, one is security. (The encryption and the codes are often kept out of the server system).

3. (Situation is to complex (performance) to be resolved inside the database).
Content based authorisation. Allthough the authorisation could be handled by joining the 'correct' tables, this would make most queries (and views) prohibitive slow.
(The complexity of this situation is far greater if implemented in the database than it is if implemented in the server coding, therefore the server coding is a better place to implement these constraints).

4.(Snapshot isolation does not prevent other transactions to alter read rows).
Depending on the implementation of the RDBMS, some checks can not be done within the RDBMS. Read-consistency (Snapshot isolation) in Oracle prevents that within a transaction you can control the change of only read rows. (Another concurrent transaction can change rows that the first transaction has only read and are required to remain the same during the complete transaction).

>>If the application was written by a competent programmer, it likes it just
>>fine.

I am sorry to say, but I have always worked with real existing and to my opinion competent programmers. (A varying degree of competence I must admit). But here (and that has been written before) I must conclude that by the newsgroup standards my organisation has always worked with NON-competent programmers. It is often said that if a certain situation arrises then the cause must be incompetent programmers. I do not agree with that. But if that is the definition of competent programmers, so be it. Then I have to accomodate for the group of programmers we actually are working with.

Back to the argument, I think that in a lot of environments the communication
between the database and the calling code the error handling and exception mechanism could be improved.
If no checking would be done by the calling code and all checking would be done by the database. The errorhandling and differentiating between different errors would give rise to more complex coding than actually checking
for those conditions before calling the database code. Inserting a 'child' record is often only allowed after the 'parent' record has
been read by the application. The database then takes care of concurrency problems (disappearing parent), but in general the application takes care of the fact that the parent should exist before inserting.

ben brugman Received on Mon Mar 01 2004 - 09:48:14 CET