Managing large files

Ian Lewis ianmlewis at gmail.com
Tue Mar 4 01:20:42 EST 2008


2008/3/4, Andrew Sackville-West <andrew at swclan.homelinux.org>:
>
> On Mon, Mar 03, 2008 at 03:21:13PM -0800, blackhawke wrote:
> > Derek Atkins wrote:
> > >
> > > Changing from XML to SQL wont change the reports.  If you fixed the
> > > reports themselves you'd get the speedup regardless of the backend
> > > storage.  The MAIN reason for switching from XML to SQL in the backend
> > > is to enable "save on commit".. So you never lose data because your
> data
> > > is saved every time you commit a transaction.
> > >
> >
> > Okay Derek, being just a dumb user I'm puzzled.
> >
> > If "save on commit" is really the only advantage to going to a SQL, then
> why
> > are SQL's so popular? I mean, they're bloody huge! I run postgreSQL;
> just
> > the DB management software is like 15M; and every database created is
> about
> > 1.5M in size just to give the software the room it needs to "manage the
> > database".
> >
> > If there's no speed advantage between, say 20,000 transactions stored in
> an
> > XML flat file and the same 20,000 stored in an SQL, then what's all that
> > software bloody doing other than playing traffic cop for multiple users?
> > :confused:
>
>
> you don't have to load all 20,000 txns into memory, for one, all you
> have to do is open access to the DB, I guess.


Indexing is another advantage, though it seems that the different database
implementations and GDA backend seem to help/hinder performance in different
ways, as is the ability of other database programs, maybe reporting
software, etc. to read your gnucash data.

Ian


More information about the gnucash-user mailing list