File store (was Re: Salutations)

[David Merrill]

On Tue, Dec 12, 2000 at 01:09:22PM -0500, Derek Atkins wrote:
> David Merrill <dmerrill@lupercalia.net> writes:
> 
> > aisb, I consider the issue of closing the books and making all
> > transactions prior to that immutable to be completely orthogonal to how
> > the running total is determined. I am proposing a solution to the
> > maintenance of running balances that scales well.
> 
> Can we assume that the Database itself can perform the necessary
> arithmatic to update checkpoints when a transaction changes?  (Yes,
> I'm showing my lack of database knowledge here -- please be gentle :)
> 
> Let me give an example...  You have 1000 transactions a day, so you do
> daily checkpoints.  Let's assume you started your data on Jan 1, 1991.
> Let's also assume that all transactions are still mutable.  On Dec 21,
> 2000 someone finds an error in transaction #1 (on Jan 1, 1991) and has
> to change the value.  This implies that every checkpoint after that
> date must be updated.  Can we assume that the database can perform
> this operation quickly and efficiently on its own?
> 
> If so, great.  Let's move on to the next topic ;) If not, then we need
> to worry about this issue.  

Using your example, there would be ~10 years of data, so that's 10 x
365 or 3650 daily checkpoints. A seriously worst-case example, let's
hope!

I timed this scenario on my machine, and I got an update time of
~200ms. It's no speed demon, either - a 400MHz PII with slow disks.
This seems quite acceptable to me, considering how unlikely your
example scenario is.

Yes, I know you can all find fault with the incredibly naive test. I
know, I know. :-)

> > I don't have an opinion on whether or not to close the books because
> > I'm too ignorant about accounting practice. I have two semesters of
> > college accounting, so I know basic concepts but that's it. I can say
> > on my own account (tee hee!) that I scored top of my class in those
> > classes, but that does not an accountant make.
> 
> Well, all closing the books really does is imply that:
> 
> 	a) transactions prior to that date are considered immutable
> 	and cannot be modified
> 
> 	b) you can place an immutable checkpoint at the date of
> 	closure.
> 
> I would think that this would solve the above update problem, since
> you know you can only update data since the last closing date, which
> limits the number of transactions (and intermediate checkpoints) that
> could potentially change.

It makes the above situation impossible.

In terms of actual *implementation*, I wouldn't put in any kind of
mechanism to make the checkpoints *themselves* immutable. Simply by
making the transactions immutable, the checkpoints themselves become
immutable. They only change when the transactions change, so the end
result is the same.

Question: What if you really *need* to go back and correct data in the
prior year?

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                dmerrill@lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org
                                       Finger me for my public key

Afternoon, n.:
	That part of the day we spend worrying about how we wasted the morning.