Re: temporary databases

Mikito Harakiri wrote:
 >

> Ruud de Koter <ruud_dekoter_at_hp.com> wrote in message news:<3CF1E5B7.BE02F58C_at_hp.com>...
>
>>Never thought about the legal implications of knowing something at a given
>>moment? Suppose someone is going to sue *you* for not saying that Exa owned the
>>flat on Jan 7. It would be very interesting to know what you exactly knew at the
>>moment you made the statement.
>
> Anyway, wrong transactions are supposed to be exception, rather than
> norm.

Except if the system learns as it goes. Take for example a hospital's set of nursing protocols -- documents that say how the staff should handle nursing situation X. The protocols are *supposed* to change over time as medical practices are improved. Ok you go to the hospital in January and have your X removed. The nurse puts in the record "patient treated with protocol X". Six months later there's a medical discovery and the protocol for X is changed. A year later you find an infection and you want to know how your original case was treated (for medical reasons, not for legal reasons :-)). In this case you want to know what the protocol was in January, but you also want the current protocol to be different from that protocol. The transaction was not wrong in January, it was the best that was known at that time, but still the record needs to be updated and the history kept. In actual usage the nurse will probably print out January's protocol and put it in your chart at the time of your care, but the hospital admins will probably want a fully searchable db of what the protocol was at differing times.

 > After discovering wrong transactions, a business
 > runs compensating transactions in order to prevent
 > any legal actions.

This kind of reduction of all thought to mental accounting gets people in trouble in the real world and in database design. What on earth would a "compensating transaction" be in the medical context? Financial transactions are often given as the prime example of a "transaction" because they are easy to explain, but the analogy breaks down when the datbase needs to model more complex events.

-- 
Jeff