Re: database integrity

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:0ecam2-fuv.ln1_at_pluto.downsfam.net...
> mountain man wrote:
>
>> "Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message
>> news:nmu0m2-gna.ln1_at_pluto.downsfam.net...

>>> then data that is
>>> valid when committed remains valid forever, it is a record of some
>>> transaction that was valid when performed.
>>>
>>> When the rules change the old data remains valid.
>>
>>
>> I am not sure that this is always correct.
>> Change certain rules and old data may not be
>> appropriate for the new rules.
>>
>
> If the fact was true when committed, a change in rules cannot falsify it.
> If I bought a widget with no VAT before VAT existed, then VAT comes into
> play, the record of my prior purchase must be valid.
>
> Can you offer a counter-example?

Yes, the series of pre-calculated NEXT_RENEWAL_DATES associated with patent applications in any country, after certain specific changes to the patent law in that country.

I have provided more detail in the thread "data integrity".

...[trim]...

>>> An integrity exception register would be interesting at upgrade time.
>>> Upon
>>> the application of some new constraint, it may be useful to mgt to see
>>> where the constraint does not apply to older data. This _may_ provide
>>> insight into how the change will impact business. In fact, running an
>>> unapplied upgrade (doing the analsysis without applying the changes)
>>> would do the same thing.
>>
>> I view the automation of an integrity exception register as
>> the automation of valuable analysis. Such analyses _may_
>> never turn anything up, in which case, you can be certain
>> (if you've built the thing correctly) that no integrity exceptions
>> identified in the register currently exist in your data.
>>
>> OTOH, the day after the implementation of a new
>> constraint, it may turn up an exception, missed in the
>> analysis, because the analyst had to leave early to go
>> for a surf before the sun set.
>>
>
> Hmmmm. In a prior life I built a system that checked for constraints
> before
> they were applied, to detect failures. This was necessary because of the
> assumption that a change in constraints would apply to old data.
>
> It was in doing this that it occurred to me that constraints developed
> over
> time should most likely apply only to data moving forward. The exception
> was a bug fix where you wanted to fix bad data, leading to the conclusion
> that both options should be supported.
>
> Now the real trick question is, how do you build constraints that apply
> only
> to new data?

The contraints would be conditional, and the conditional expression would seek reference to (for example) a date of entry to the system or some other parameter which could service the requirement to differentiate what you want to call "new" from that which is "existent" or "not-new".

Pete Brown
Falls Creek
Oz
www.mountainman.com.au Received on Wed May 25 2005 - 08:42:01 CEST