Re: database integrity
From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Sat, 04 Jun 2005 12:44:22 -0400
Message-Id: <bg29n2-vkk.ln1_at_pluto.downsfam.net>
>
> I think the problem here is simply that this is denormalized data, with
> all the usual problems thereof. These future dates are the output
> of some application-specific function of the patent application date,
> and aren't primary data at all. Hence, when the function changes,
> the data is no longer valid.
>
> I think it is sufficient simply not to store this data and to generate
> it
> on demand according to the current function.
>
>
> Marshall
Date: Sat, 04 Jun 2005 12:44:22 -0400
Message-Id: <bg29n2-vkk.ln1_at_pluto.downsfam.net>
Marshall Spight wrote:
>> I would say at first glance that data should not be generated that far in >> the future. Consider this. You know that the law can change, and >> therefore the data _cannot_ _be_ _considered_ _valid_ _when_ _saved_, >> therefore it should not be saved. It is not that the data was valid and >> then became invalid, it is that it was never valid in the first place.
>
> I think the problem here is simply that this is denormalized data, with
> all the usual problems thereof. These future dates are the output
> of some application-specific function of the patent application date,
> and aren't primary data at all. Hence, when the function changes,
> the data is no longer valid.
>
> I think it is sufficient simply not to store this data and to generate
> it
> on demand according to the current function.
>
>
> Marshall
What makes it denormalized? Methought we had a temporal issue, speculation being committed as fact.
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth_at_(Sec)ure(Dat)a(.com)Received on Sat Jun 04 2005 - 18:44:22 CEST