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

Kenneth Downs wrote:
> We see strong value in converting derived values into stored values.
This
> is what led me to a systematic way to define derived values, and
ultimately
> this path led to very large code eliminations.

Always a good thing!

> That being said, the moment that the user supplies data is the best
time to
> store as well the derived information. This allows their retrieval
in a
> way that is really and truly "at will", inasmuch as the SELECT
command can
> be exected at will.

I disagree that it's the "best time." Logically, it makes no difference when the value is computed, so long as it is correct, so we're only speaking of performance, right?

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

> All other solutions depart from this maximum efficiency. The problem
is
> shifting definitions over time. When formulas change over time, you
have
> to jump through some serious hoops to preserve the ability to
reproduce
> historical information.

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?

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.

Hopefully all of the above is done automatically via declarations, by the "engine" we're discussing?

> On the other hand, if you materialize the values, they are protected
against
> shifting definitions.

But you don't always want that protection.

> Thanks for the reading list, I will look over it. I'm aware of the
LISP
> treatment of code and data, but I think that is far afield of this
> conversation. The others I would have to peruse before commenting.

I don't really think it is - while a different approach, the aims are not entirely different.

• erk