Re: temporary databases

Jeff Zucker <jeff_at_vpservices.com> wrote in message news:<3CF9C432.50502_at_vpservices.com>...
> Mikito Harakiri wrote:
> >
>
> > Ruud de Koter <ruud_dekoter_at_hp.com> wrote in message news:<3CF1E5B7.BE02F58C@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.

There is no wrong transactions in that context (except malpractice), indeed.

> 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 :-)).

The time when discovery has been made, and, more important, when substitute protocol Y got certification, both could be ignored. (We assume that nobody would sue the hospital in case when Y has been certified already, but the hospital was slow in adopting Y). We record the time when protocol Y is adopted in hospital's practice, instead.

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

I don't see why your example requires Transaction Time. We have:

Table Protocols (

    protocol varchar2,
    effective date,
    expired date
)

Table Treatments (

    patientName varchar2,
    symptom varchar2,
    protocol foreign key refers to protocol id,     applied date
)

All these timestamps seems to be "valid times" to me. A hospital admin can query any history of patient's treatments, and verify that no protocol has been applied after its expiration date.  

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

A person get shot. Compensating transaction would retrieve the bullet and do some healing.

Seriously, the discussion here is about significance of "transaction time". Can we formally define the difference between "transaction time" and "valid time"? Do we need any special temporal operators that allows one to query the intervals between valid time and transaction time? Received on Sun Jun 02 2002 - 20:28:14 CEST