On Tue, Dec 12, 2000 at 01:09:22PM -0500, Derek Atkins wrote:
> David Merrill <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
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.
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
