Re: database integrity

mountain man wrote:

> "Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message
> news:0ecam2-fuv.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

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

Each time a NEXT_RENEWAL_DATE needs to be recalculated, a new row should be put into the table of renewal histories. The old value should never be overwritten.

But this does not sound like a change in rules, but a periodic update of the patent.

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

Why not just fire some constraints on INSERT, others on UPDATE and so forth. Or is this what you mean by conditional?

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)