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

erk wrote:

> Kenneth Downs wrote:

>> erk wrote:
>> > "Extended" isn't data.
>>
>> No?  My customers are not mathematicians.  To us ignorant rubes it is

>> as surely as the price and item code are data.  Given a choice

>> "theory" that provides no guidance for real needs, and a practice

>> does, I say the practice is the better theory.

I was overly curt as well, apologies offered.

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.

<big snip>  

>> All I can say is try with 750+ tables, 10,000+ domains, calculated
>> prorations, calculated aggregrates (including fun ones  like weighted
>> averages).  In fact, perhaps I can put you in touch with a shop I

>> they'd love to find out how to produce this stuff "at will".

I will stick to the assertion that we cannot admit use of the term "at will" for anything but stored values. Or at least, when stored values are considered, they claim the term to such an extent that no other solution is in the running. Consider:

First, assume the existence of a format that we have agreed upon for specifying formulas.

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.

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. If you use views then you have to have multiple views based on dates, which gets ugly fast. If you use sprocs they become loaded with cases and conditionals. While one might argue that this is all computer-generated and therfore not a problem, they are still more complicated then simply retrieving a column from a table.

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

>> >
>> > I think there are many. Unfortunately, the interesting ones were
>> > developed and discussed decades ago, before the demand for

>> > drove explosions of languages, "framework", and semi-trained
>> > developers.
>>
>> Name two.  I love a good read.

<snipped>

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.

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