Re: Arbitrary Constraints

From: Alan <alan_at_erols.com>
Date: Tue, 26 Oct 2004 10:11:31 -0400
Message-ID: <2u748lF27jqobU1_at_uni-berlin.de>


"Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:hbcllc.lf2.ln_at_mercury.downsfam.net...
> Last week I mentioned that I believed unique and referential constraints
are
> 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.
>
> 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.
>
> 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
I
> may have to fend off a lot of constraints that could be dealt with with
RI,
> 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.
>
> --
> Kenneth Downs
> Use first initial plus last name at last name plus literal "fam.net" to
> email me

The really simple ones (like inventory >=0) can be dealt with by CHECK constraints (in Oracle, anyway).

I believe the other types of constraints you are talking about have to be dealt with on a case-by-case basis. For example, the salary cap. Sounds easy to "generalize" into a pre-built universally usable contraint of some sort, except that one organization's method of determining the cap may be different than another's. Or it may be complex- if your current salary grade is D, and you work in departments 3, 6, or 7, then your cap is x etc, etc...

Normalization rules deal with data at a very general, and most importantly _abstract_ level. When normalizing, one does not even consider the actual values of the data, just their relationships. The types of constraints you are referring to deal with values, and once you start dealing with values, generalized code goes out the window. These types of constraints need to be dealt with individually. What you are searching for smacks of the I.T. holy grail- reusable code. Many thought OO would deliver it. Ain't gonna happen with constraints, either, IMO. Received on Tue Oct 26 2004 - 16:11:31 CEST

Original text of this message