Re: Multiple specification of constraints

"ben brugman" <ben_at_niethier.nl> wrote in message news:403e2973$0$1416$4d4ebb8e_at_read.news.nl.uu.net...
> I agree with most that is allready replied.
> Constraints should be centralised. But the problem
> is often where and how.
>
> Constraints which can be enforced in the RDBMS system
> should be enforced there. (If the constraint is not to complex).
>
> Then most applications (server or client) will enforce a constraint
> again, because the application does not like the exception handling
> when a constraint of the database goes 'off'. For the GUI it is a
> lot handier to remark there is no data the 30th of februar
> (except in sweden) or that data is on a sunday and you can not
> use that date, than to do the database access and get an error.
> So most programmers doing the data access still have to know
> the constraints to anticipate on them, same goes for the Gui programmers.
> (I hate web applications which first ask all the questions and in the end
> tell me that I am not allowed to do something because of .....)

If I understand you correctly, you are actually IN FAVOR OF DUPLICATING THIS COMPLEX DATA -- locating it once in the database and again in a different language in the business rules used by the GUI. Is that correct? It does seem like you are in the majority, but I just don't see what is gained by coding these rules twice in different languages -- sounds like busy work that leads to complex-to-maintain software and is likely to be out of synch with itself, with app programmers prone to change only the application software and not the dbms constraints when they can do so.

>
> Then there are constraints which are more difficult or impossible
> to implement in the RDBMS, and although the constraints should
> be 'kept' centralised. These have to be enforced outside the RDBMS.
> (Some database people say that if a constraint can not be implemented
> in a database, then it can not be a real constraint. I do not agree with
> that.)

"Centralized" is fine, but another minor point today (more major perhaps in the future) is that the database could be one of many accessed by the software application, so that a central place for the business logic / constraints / data validation information would more likely be within the software code that is external to one of the databases, right?

>
> The advantage of enforcing the constraints in the RDBMS over
> another centralised system is that it also protects against concurrency
and
> that it is often better scalable than a 'coding' solution.

Let's say that we have no issue with scaling on this or even find it better not to have to go to the database to find that the valid options for radio buttons on a flag are True & False, or that a valid date is one on a calendar. What is an example of the biggest risk related to concurrency? If the spec of a constraint is that a field needs to have a value that comes from a list of stored data, then the database would still be read to get that data -- just not, perhaps, to find out the name of the table that needs to be used. But I suspect you are on to something I'm missing, so please advise.

<snip>

Thanks. --dawn Received on Thu Feb 26 2004 - 21:16:40 CET