DBMS Usage

[Paul Lussier]

In a message dated: Wed, 03 Apr 2002 14:10:43 EST
Christopher Browne said:


>Editing the existing XML file is not all a bed of roses, by the way.

Never said it was, but the fact that I can if I need/want to, is better 
than not being able to at all.

>Frankly, the problem _today_ has to do with neither of these, and will
>not be solved by changing the way data is stored.
>
>The problem that was had 8-odd years ago with CBB

(has it been *that* long? Crikey, seems like yesterday :)

>which continues today, to some extent, with GnuCash is that the
>_display widget_ performs increasingly poorly as the amount of data
>associated with the register increases.
>
>With CBB, that was the Tk "array" widget, where modifying anything
>required recomputing the whole array, because it wasn't smart enough to
>know to change just those bits that actually changed.  
>
>With GnuCash, changing the date on a transaction could lead to a whole
>cascade of data changes if that change moved a transaction from bottom
>to top.  Every balance along the way could need recalculating, for
>instance.

Okay, this makes a lot more sense to me now.  However, how would 
changing the under lying data format from ascii to binary affect this?

Doesn't the application still need to make all the same screen 
updates were the same change made?  Are you saying that by pushing 
the calculation engine outside of GnuCash to a DB would somehow speed 
things up with respect to how fast the display could update?

I definitely agree that by pushing things out to a backend database 
would lessen the amount of code required in GnuCash ( I don't like 
it, and I don't want to see it happen, but I agree with the 
statement).  But I don't understand how that will affect screen 
updating.  Doesn't the application still need to read in the same 
amount of data and display the same bits on the screen?

Thanks,
-- 

Seeya,
Paul