Re: temporary databases

From: Ruud de Koter <>
Date: Tue, 28 May 2002 10:43:54 +0200
Message-ID: <>

Hi Mikito,

Mikito Harakiri wrote:
> Ruud de Koter <> wrote in message news:<>...
> > 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.
> OK, if lawyers are involved I give up. However, letting layers to
> define database model maybe is not such a good idea.

I wouldn't say lawyers should define database models either. At the same time I know lawyers are a part of the real world in which your database has to function.

> > Still think this is a theoretical situation? Go talk with a real customer in the
> > insurance business, or stock exchange.
> I assume that the legal implications could be triggered by wrong
> transactions only. After discovering wrong transactions, a business
> runs compensating transactions in order to prevent any legal actions.
> Compensating transaction might be as simple as just returning
> customer's credit. Compensating transaction can refer to wrong
> transaction, so that a business would still be able to query
> transaction history for errors, or what did they know at the moment,
> if you like.
> Anyway, wrong transactions are supposed to be exception, rather than
> norm. Therefore, "transaction time" is just unsound abstraction
> level.

I happen to have some practical experience working for pension funds. These institutions certainly do not see mistakes being made as 'wrong transactions'.

Just think about one example: a baby being born. You send around lots of cards, and whom do you forget: the pension fund. Only when you receive your annual summary of pension rights, you realize your kid 's not on it. And then, only a hypothetical eight months later, you let the fund know you have a child.

Now, it seems pension funds have long ago realized this is the way people go about their lives. They insist that their application allow them to register the fact that they were informed on November,8 that a child was born on February, 15. They will register that the child was born in February, and grant it whatever rights are appropriate from that date on. They will also register they only knew this in November.

This is important because only this kind of registration will allow them to come up with a good bookkeeping overview regarding the past. Say you want to know the fund's oblivgation as they were July, 1. In this computation the hypothetical child should not turn up, as its existence was only known to the fund in November. This also applies when the computation is executed in December.

So, in short, this kind of registration is useful for important real life issues. It might not be your way of looking at life (nor is it mine), but these things are important for insurance companies and institutions like that.  

> We learned from transaction theory that it's a good idea to
> eliminate combinatorial state
> explosion when transaction participants are allowed to see
> each-other's intermediate states (no isolation).
> "Transaction time" is increasing modelling complexity level instead of
> decreasing it, because you consider much more states.
> > Just as an aside: be a man, write under your own name.
> I forwarded your suggestion to Samuel L. Clemens.

Who wrote fiction, didn't he?


Ruud de Koter.

Ruud de Koter                    HP OpenView Software Business Unit
Senior Software Engineer         IT Service Management Operation
Telephone: +31 (20) 514 15 89    Van Diemenstraat 200  
Telefax  : +31 (20) 514 15 90    PO Box 831
Telnet   : 547 - 1589            1000 AV  Amsterdam, the Netherlands
Email    :

Received on Tue May 28 2002 - 10:43:54 CEST

Original text of this message