Re: Arbitrary Constraints

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Tue, 26 Oct 2004 18:02:04 -0500
Message-ID: <clml1n$fh4$>

"Kenneth Downs" <> wrote in message
> Last week I mentioned that I believed unique and referential constraints
> not used to their full potential, and that they could be used instead of
> some of the constraints we see today. Several kind souls argued the other
> side of this and helped me to solidify my thoughts. Thanks.
> Now I have arrived in this particular project where it is time to
> systematically deal with non-structural constraints. I use the word
> "arbitrary" to describe them to emphasize their volatility.
> An arbitrary constraint is one that appears, from the point of view of
> normal forms, to pop up out of nowhere after the fact. Consider that you
> put all of this time into normalizing tables, and then somebody says, "Oh
> yes, each customer has a credit limit, and open orders cannot exceed the
> credit limit." This appears as an arbitrary relationship between columns
> that cannot be dealt with in normalizing them. A filter comes into play
> one way or another.

Are "constraints" the same thing as "business rules"? Have do constraints relate to application logic? If you remove all such constraints from "application software" and make these constraints available to both the database and the UI, what would be left for the application software to handle? This is not a question for which I have an answer, but am definitely interested.

> What I would like to do now is determine if the most commonly encountered
> "must have" constraints out there in fact have commonalities to them so
> that they can be handled with a finite number of types, macros, or
> utilities, and so their apparent arbitrariness can be categorized and
> "normalized" as it were.

A good idea to at least have some design patterns or best practices.

> For instance, last week's example of the salary cap can in fact be dealt
> with with a salary lookup table. Some did not like this solution but in
> the first pass we are dealing with technical possibilities and
> impossibilities. We have to gather them altogether before making a
> judgement.
> The next category I saw was the two-column relationships. Open Orders <=
> Credit Limit, Qty_Shipped <= Qty_ordered, things like that.
> This may be a can of worms in asking for more constraint examples, because
> may have to fend off a lot of constraints that could be dealt with with
> but what I think I'm looking for are the very simple cases that are not
> obviously structural, like simple credit limits, inventory >= 0 and so
> forth.

Lots of date constraints in stuff I've worked on. Also a lot of simple validations, validating differently based on a parameter, upcasing ... I might not be catching on to the type of constraints you are looking for, however. But it sounds like a good idea to work on such a lassification. --dawn

> --
> Kenneth Downs
> Use first initial plus last name at last name plus literal "" to
> email me
Received on Wed Oct 27 2004 - 01:02:04 CEST

Original text of this message