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

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

...[trimmed]...

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

It depends on the workflow queues (or lack thereof) established by the organisation to manage its business, IMO. Credit control starts with this notion of "credit limit", and ends with the routine chasing of outstanding debt.

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.

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.

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.

Pete Brown
Falls Creek
Oz
www.mountainman.com.au Received on Fri Apr 15 2005 - 02:59:15 CEST