Re: Validation Rule
- From: Klatuu <Klatuu@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 25 Aug 2005 09:42:10 -0700
Tim,
I don't disagree with the theory behind anything you say; however, please
try to live in the real world. We cannot always control the data we are
provided or the contraints put on us by complex business logic.
The database I support, I beg on a daily basis to be allowed to totally
redesign and remodel it, but am not allowed the privledge.
"Tim Ferguson" wrote:
> =?Utf-8?B?S2xhdHV1?= <Klatuu@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> news:4B57C0CB-8C6B-4F6B-AFC6-9B23134220E7@xxxxxxxxxxxxx:
>
> > Too many times I have seen databases so
> > over-normalized they were almost useless. This is just as poor a
> > design as an unnormalized, unprotected database.
>
> I think we must have different ideas of what normalisation means. There
> is no such thing as "over-normalisation" -- there is only inadequate
> analysis. If a database does not model what it's there to model, then it
> has been done wrong, and any application of R theory or denormalisation
> is not going to rescue it.
>
> > Here is why, in my case, we have some tables that have to allow
> > incomplete data.
>
> Normalisation has nothing to say about completeness of data. R theory has
> a little to say about the use of NULL data, but completeness or otherwise
> is purely a matter of semantics and that is a matter of analysis.
>
> > A new project is approved ... that incomplete data exists.
>
> I did not follow the example, but suffice it to say that analysis is not
> neccessarily easy. Complex business procedures are harder to model than
> simple one. As the USians say "suck it up"... it's why good systems
> analysts get paid a lot of money.
>
> > The other problem I have experienced in more that one application is
> > that table/field validation is not robust enough to do complex cross
> > field validations.
>
> If you mean that real-life dbms implementations have limitations, then of
> course you are right. Moving up from cheap desktop platforms to more
> sophisticated enterprise systems allows more complex constraints. There
> will always be something that someone needs that cannot be achieved with
> present day equipment. But it's pretty rare in practice and not relevant
> to this discussion. Way back in the mists of time, this thread's OP
> wanted to compare two dates: even jet/access 1.1 could manage that!
>
> > This then, brings me to a question. Let's
> > say in a table Field_1 must be either "RR" or "NR" (easy to do). But
> > then, if Field_1 is "RR", the Field_2 must be a one of a list of 5
> > values but if it is "NR" then Field_2 has to be empty and Field_3 can
> > be either empty or one of a list of 10 possible values.
>
> There is a complex set of functional dependencies here, and it needs a
> lot more close inspection. I strongly suspect that a different design
> would be in order, but only with a great deal deeper understanding of
> what is on offer here.
>
> B Wishes
>
>
> Tim F
>
>
>
>
.
- References:
- Validation Rule
- From: Doreen
- Re: Validation Rule
- From: Tim Ferguson
- Re: Validation Rule
- From: Klatuu
- Re: Validation Rule
- From: Tim Ferguson
- Validation Rule
- Prev by Date: Re: Programatically Determining What Data is used Where
- Next by Date: Re: Validation Rule
- Previous by thread: Re: Validation Rule
- Next by thread: How to fill a combobox with DSNs with are stored
- Index(es):
Relevant Pages
|
