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

mountain man wrote:

> "Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote:
> in message news:99d2j2-rkq.ln1_at_pluto.downsfam.net...

>> erk wrote:

>>>> On the other hand, if you materialize the values, they are protected
>>> against
>>>> shifting definitions.
>>>
>>> But you don't always want that protection.
>>
>> Believe it or not, I agree.  Having made the case as best I can above, I
>> woulld offer that you probably don't want stored values for things like
>> summary tables (although I do have a nifty trick to do that in real-time
>> w/o update conflicts).
>>
>> Here is a case where I have not made up my mind.  Consider a derived
>> value,
>> customer total exposure.  It is built up through composition from orders
>> and invoices.  There is another derived value, customer credit limit.  By
>> making use of simple formulas and composition, we can begin to establish
>> constraints as simple comparisons of these values, so that "customer
>> total
>> exposure" must be < = "credit limit".  Materializing up to the customer
>> table runs the risk of update conflicts, but then again how often are
>> multiple people writing to the same customer?

No chasing, that is procedural. The outstanding debt is defined in terms of other columns, and is updated within any transaction that affects any of those columns. Credit Control is now resolved to a table constraint. Voila, we have turned a process into table/column definitions.

>
> A credit control module I have found to be the best approach in
> that additional info required by the credit control workflow
> process can be maintained not against the client table directly,
> but against a separate subset of those clients.

Again, if the "process" is just one of Mr. Celko's "little worms" that crawls through data, throw it away and replace it with a definition of the final value built up through composition. If you have client subsets, make a table for them and work it into the formulas.

>
> For the instance you discuss above, the credit limit, I have found
> that this resolves also to an alert queue to be possibly acted upon.
> Your business rules will define what you have to do about credit
> limit excesses, but the collection of clients falling into this category
> in the first instance is a daily report, for example.

SELECT customer,customer_name
 FROM customers
 WHERE total_exposure/credit_limit > .9

run report at leisure.

>
> I am not sure whether I have assisted you on this issue.
> Business mechanisms and culture are often quite different
> between the US (where I presume most ppl are) and Australia.

Thoughtful discussion always helps. Hope it has been as helpful for you as for me.

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