WHY use anything other than an XML backend?

[John Layman]

Yes, I understand all those points, but ...  Suppose I did have a database
containing a quarter century of financial data but I lost track of how it
was I made that last donation to the Red Cross.  Now, I go to the Accounts
tab and launch a search for "Red Cross".  Do I really want a result set 25
years deep, even if it is date ordered?  Not really.  But, of course, that
is the sort of nuisance that could be solved by adding terms to the search
feature.  The costs I was referring to weren't in database performance,
anyway.  I'm talking about cost related to how long backups require, how
much space they consume, etc.  AND it seems to me there are usability
considerations in all this.  If the account structure in my personal and
business files actually included every bank account, credit card account,
investment, etc. over the quarter century period.  Horrors!   Through a fair
amount of effort, I started my GnuCash books as of January 1st, 2010 and
imported just the *living* prior investment, mortgage loan, home
improvement, credit card entries, etc.  Some of this stuff is in hidden,
closed accounts.  I shudder to think what I'd have without some ability to
purge dormant data.  Perhaps a variation on account hiding where you could
place an account in deep-six status... Hmmmmm.



-----Original Message-----
From: John Ralls [mailto:jralls at ceridwen.us] 
Sent: Wednesday, April 20, 2011 3:47 PM
To: john.layman at laymanandlayman.com
Cc: Users Gnucash
Subject: Re: WHY use anything other than an XML backend?


On Apr 20, 2011, at 10:29 AM, John Layman wrote:

> I realize the oxymoron.  From a practical standpoint, things called 
> IMDBs wind up being a hybrid.  Anyway, the advantage is purely 
> performance.  Even given paging activity, there's a good chance an 
> IMDB will entail less I/O than a conventional DBMS.
> 
> As for purge/archive.  I first started using online banking and 
> maintaining financial records on a PC in a pilot program for Banc One 
> sometime in the vicinity of 1984-5 (if memory serves.)  I switched to
Quicken circa 1988.
> Because I loathe Intuit and got sick of their never-corrected defects 
> and lousy support, I switched to Money H&B somewhere along the line.  
> I've been using GnuCash since 01-Jan-10.  If I were to have retained 
> all my financial data from this quarter century, I would be lugging 
> around a monstrous working dataset only a fraction of which had 
> present value.  That would not come without cost in several forms, and the
benefit to the user strikes me
> as slight, to say the least.   I appreciate that designing such a feature
to
> work well would be a major challenge, and perhaps that is the "economic"
> benefit of leaving the problem unaddressed.  But I think it would be a 
> mistake to simply suppose that this is a non-problem.  I've seen the 
> issue raised again and again here in the course of the year-plus I've 
> been monitoring this list, and I don't consider it to have come up 
> simply because Quicken and/or Money set a precedent in the users' 
> minds.  Ever pause to consider why Intuit and Microsoft went to all 
> that  trouble?  Maybe GnuCash isn't really immune from whatever their
reasons may have been.

There's a really simple test: Do you have to save your work when you quit
the application? If so, then it's some sort of a whole-dataset-in-memory
backend and you have to split parts of it off from time to time to keep it
from getting sclerotic.

A well designed database backend, on the other hand, only loads what it
needs for the task at hand (perhaps adding some predictive preloading for
performance), so there's no need to reduce the database size unless one
starts to run short of storage space. That *was* an issue in the mid-80s,
when storage ran as high as $500/MB, but not so much of a concern these
days. Memory was also a much greater issue for PC users until WindowsNT and
MacOSX became popular; neither the DOS-based Windows (meaning everything up
through ME) nor Macos through System 9 provided credible virtual memory;
that created another major performance hit as file size grew.

As I've been relentlessly pointing out, though, Gnucash does not yet have a
well-designed database backend, nor does the core support one even if we
did. At present we are very much affected by the poor load & save
performance (though on today's systems financial data, even decades worth,
does not tax the GB of memory and TB of storage available on even the
lowest-end systems so performance isn't much affected while the program is
running).

Regards,
John Ralls