Re: the relational model of data objects *and* program objects

erk wrote:
> in response to what Kenneth Downs wrote:
>
> Logically, it makes no difference
> when the value is computed, so long as it is correct, so we're only
> speaking of performance, right?

True - who cares how it is done, if the right answer is presented in a timely and reliable fashion.

> From a performance standpoint, then, it makes sense to compute values
> during non-peak times - only if possible, of course. A value that's
> requested must be computed if not already stored. But recomputing for
> every change means more wasted work.

Perhaps it is wasted, perhaps it is mandated - a business rule IMO!

> Another school of thought would say that if the formula is changing,
> then presumably the previous values were wrong. If a formula change
> produces "new historical values," does that mean the previous ones were
> wrong?

Not at all. For instance in my corner of the world we recently had a GST/VAT foisted upon us unsuspecting citizens. At the appointed date/time the "formula" for calculating "Extended" changed and a widget bought a day later cost 10% more than the day before!

> More likely is a hybrid context: a formula change will affect some
> values and not others. Stored values makes this and the "all old values
> are wrong" cases difficult.

Simply a design issue - either in the schema or the programmes or both!

Cheers, Frank. Received on Thu Apr 14 2005 - 17:05:07 CEST