WHY use anything other than an XML backend?

John Ralls jralls at ceridwen.us
Wed Apr 20 15:46:49 EDT 2011


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



More information about the gnucash-user mailing list