"Stuart D. Gathman" <[EMAIL PROTECTED]> writes:
>> (A) The program needs to be able to generate multiple arbitrary books (files)
>
> Sounds complicated. I don't see what this accomplishes that is
> different than decent indexing in a database.
This presumes we HAVE a database. That's the main problem (IMHO).
The main storage technology is an XML file, which means all your
data needs to be in-core all the time. If you have data back to
1980 then you need to hold all that data in-core. This makes it
VERY slow.
Changing to a database backend (like SQLite) as the default storage
mechanism should help significantly.
At this point most of the reports already have a start/end date to
deal properly with accounts constantly growing. OTOH, it's nice to be
able to look at your income/expense account balance and see YTD sums
without resorting to a P&L report.
I agree that all the copying is probably overkill, but it's necessary
while we still maintain XML. Perhaps Linas' time would've been better
spent fixing the SQL code and working on a migration to SQLite?
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
