Re: Multiple specification of constraints

"ben brugman" <ben_at_niethier.nl> wrote in message news:4042f8ce$0$268$4d4ebb8e_at_read.news.nl.uu.net...
>
> > > Then there are constraints which are more difficult or impossible
> > > to implement in the RDBMS, and although the constraints should
> > > be 'kept' centralised.
> >
> > 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).

i.e. One made an arbitrary decision not to manage the data. This does has nothing to do with difficulty or impossibility.

> 2. (Security is kept outside the database.)

i.e. One made an arbitrary decision not to manage the data's security.

> (The encryption and the codes are often kept out
> of the server system).

I suggest you switch to a secure server. Communicating codes from another source only adds an opportunity for interception.

> 3. (Situation is to complex (performance) to be resolved inside the
> database).

If it is too complex to resolve within the dbms, it is necessarily too complex to resolve anywhere else.

> 4.(Snapshot isolation does not prevent other transactions to alter read
> rows).

Poor choice of dbms does not relate to difficulty or impossibility.

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

Or removed entirely.

> If no checking would be done by the calling code and all checking would be
> done by the database.

A database is a set of facts. It does nothing on its own. A dbms does things. A file processor does things. An application does things. A database just is. Received on Tue Mar 02 2004 - 05:07:22 CET