Re: Multiple specification of constraints

"ben brugman" <ben_at_niethier.nl> wrote in message news:4043049f$0$269$4d4ebb8e_at_read.news.nl.uu.net...
>
> And most discussions in this 'newsgroup' only concern constraints
> which do apply to the database.

It's a database theory newsgroup, so this should not be a surprise.

> (This is the set of data which is
> still present, after the machine is shut down.

Ack! That's not a good definition! RDBMSs are primarily about data management, not persistence. They happen to be a good place to implement persistence as a service, but there are other things that can do that too just as well. But those things can't do data management.

The idea that databases are primarily about persistence is toxic myth. You can have persistence without data management, and you can have data management without persistence.

>Well the constraints
> 'are' not present, but the data still conforms to that set of constraints).
>
> Then the centralising of the constraints. I do not think the implementation
> can be 'totally' centralised. But a nice situation would be that the
> model with all constraints is somewhere centralised in some form.
> (Documentation or something).
> This set of constraints has to be implemented and the implementation
> can be redundand. (In the code and in the database.)

> Example there is an implementation of 'child' and 'parent' in the database,
> the database holds the constraint the 'parent' must exist everytime a
> child exists. Often the application is build in such a way that even if
> the constraint is dropped in the database, the application only can
> 'make' data in accordance with the constraint. Often the application
> can not 'violate' a constraint if it is the only application.

It is important to differentiate between application constraints and data constraints. Something that is only necessary for one particular application and not for others is not a data constraint, and does not have the same centralization requirements.

> My point :
> All constraints should be 'included' in the model 'documentation'.
> (This is considered centralised.)

Not by me it isn't.

> Implementation of constraints should be done as close as possible
> to the data, preferably in the RDBMS.
> (The implementation can be centralised, but I think this is not
> realistic for all situations).
> Server and application coding often do implement a part of the
> constraints implemented in the database. (The risc here is that
> different software has different implementations of the 'same'
> constraint).

That's why centralization is essential.

Let's put it this way: you centralize the constraints for the same reasons you centralize the data. In fact, the constraints *are* a part of the data; that's why you can't separate them.

> Then some constraints are only implemented outside the RDBMS,
> the risc here is different implementations of the 'same' constraint and
> no central enforcement (RDBMS) of the constraint and over time
> the constraint can be changed (switched on or off or can be different).
> This gives the risc that even if a constraint is implemented that there
> is data not in accordance with that constraint.

This is another problem with centralization solves.

Marshall Received on Mon Mar 01 2004 - 17:15:56 CET