Tony wrote:
> Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net> wrote in message
> news:<b6ogkc.34m.ln_at_mercury.downsfam.net>...
>> Tony Andrews wrote:
>> > Now in case (1) the total is sure to be right, whereas in (2) it could
>> > be wrong because our stored total has somehow got out of sync with the
>> > detail data. Yet this is somehow seen as a "good thing", because if we
>> > add up all the details and find that that DO agree with the stored
>> > total (as they should), we somehow have more confidence in the total.
>> > Why? I am sure I must be missing something.
>>
>> The total in case 1 is sure to be wrong, which I state from the
>> experience
>> of watching it happen. This is because it is very easy to consider the
>> case of extended price = price * qty, and from there to imagine that
>> Order
>> Total = SUM(extended price). What could go wrong, right? Who could mess
>> that up?
>
> Well, that wasn't quite what I meant. The case (1) total should be
> provided by a mechanism such as a view - as if it were a stored total,
> but not actually stored. I'm not suggesting it is better if users
> work the total out for themselves!
The view has its own problems. The view is a stored bit of code and so
suffers from the same problems as procedural code, it can get changed over
time. Complexity is also an issue if they are built by hand.
--
Kenneth Downs
Use first initial plus last name at last name plus literal "fam.net" to
email me
Received on Wed Oct 13 2004 - 06:22:48 CDT
