Re: Multiple specification of constraints

>
> 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.
>
Input of a date for example, it is fairly common dat the Gui only accepts real date's. The constraint that there is no 30th of februar is checked in the Gui and it is checked again in the RDBMS. Often when entering information, for example lending a book, this can only be entered for an existing lender. The application does not allow to enter a non existing lender and the RDBMS still checks that that the lender does exist.

>
> "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?

If the software is used for more than one database and the database is not used for different types of software then the coding in the software has to be
done only once. But in the past it has been more likely that the software will
change than that the database will change.

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

Some constraints are based on data read, if these constraints are done in the database, there is no concurrency issue. If you check the total amount of
data in the application the read data has to be locked. (Predicate locking). Oracle for example does not allow predicate locking so there you have to find a way around it. Checking the constraint in the database does not have this problem.

For example two partners have both their own bank account, they are allowed to have an overdraft, but the two accounts together must be kept out of the read.
If this constraint is implemented outside the database, depending on the way it is implemented, both partners will be capable of overdrafting their own account
if the timing is 'perfect'.
A real 'serializable' level does prevent this, but Oracle does not supply a real 'serializable' level. So then you might be better of to implement this constraint
in the database, so that when to transactions occure at the same time the constraint is still checked against correctly.

ben brugman.

>
> <snip>
>
> Thanks. --dawn
>
>
Received on Fri Feb 27 2004 - 17:35:36 CET