Re: Multiple specification of constraints

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:%kJ0c.94816$4o.117703_at_attbi_s52...
> "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 'definition' concerns the database, not the RDBMS or not the (RDBMS-)instance. So for the database the definition 'holds'. For a RDBMS or a (RDBMS-)instance you are correct. The database part is only the persistence part which can be recovered after a crash. (But I must admit that I often use the term database where RDBMS should be used. In the above case I didn't).

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

Databases are about persistence. RDBMSses are about the system around the database.

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

Constraints are requirements of the 'user', or the 'one' who is defining the system. At specification time of the requirements it does not have to be clear if a constraint will be implemented in a database or in any other way. So a specification time for some constraints it is not possible to differentiate between appliation constraints and data constraints.
When implementing the differentiation has to be made. But before implementing
it would be nice to have all constraint somewhere centralised.

>
> > My point :
> > All constraints should be 'included' in the model 'documentation'.
> > (This is considered centralised.)
>
> Not by me it isn't.
Ok.

(Refraise : The requirements should give or dictate the constraints. The requirements should be a complete set. It would be nice that the set is not scattered over several systems/documents/buildings).

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

No it is not, we run a legacy database only capable of implementing very rudimentair constraints and constraints have to be implemented into the coding. We have survived in the marked without this essential centralization. So centralization is not essential for survival.

And you can see from my other mails that I have given some examples where constraints outside the RDBMS is the 'best' option. And also in one of the mails I described that some people call constraints outside the RDBMS as non database constraints. I do not agree with that. But I must agree it is debatable when a constraint is a database constraint and when it is not.

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

No it does not. If the centralization is done in application code it does not solve the problem. And if different database venders are used it does not solve the problem either. (Two databases can not be centralised in one RDBMS).
If the constraints are implemented with triggers than this problem is not solved either.

I agree that referential constraints and domain constraints should be implemented in the RDBMS (if possible, using two databases does not allow for referential constraint checking within one RDBMS). But a lot of constraints (which I still think of as database constraints) are implemented outside the RDBMS.

ben brugman.

>
>
> Marshall
>
>
Received on Mon Mar 01 2004 - 18:08:39 CET