WHY use anything other than an XML backend?

[John Layman]

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.

-----Original Message-----
From: John Ralls [mailto:jralls at ceridwen.us] 
Sent: Wednesday, April 20, 2011 11:37 AM
To: john.layman at laymanandlayman.com
Cc: 'Geert Janssens'; gnucash-user at gnucash.org
Subject: Re: WHY use anything other than an XML backend?


On Apr 20, 2011, at 7:58 AM, John Layman wrote:

> It seems to me the advantages of using a DBMS lie in the ability to 
> handle a huge data store efficiently, to access the data using 
> standard tools, and the potential for evolving GnuCash in a multi-user 
> direction.  But there is much to be said for the benefits of an 
> in-memory data store.  Instant saving is not an unqualified advantage.  
> It would be interesting to know how frequently users resort to the 
> close-without-saving feature using XML.  If I am at all typical, that is a
'feature', not a weakness.
> 
> There is little significance in what the backend might be unless the 
> data design is normalized and referential integrity is enforced.  Just 
> stuffing the current data design into a DBMS really only solves the 
> data volume problem.  I do think that it is unrealistic to expect the 
> data store to grow ad infiinitum, regardless of where the data are 
> stashed.  A purge/archive function of some sort is still very much 
> needed.  This is something Microsoft Money did remarkably well.  It 
> could remove transactions older than a specified date, while 
> preserving those older transactions (and their possibly closed 
> accounts) that connected in some way to on-going information requirements
such as investments and mortgages.

It doesn't even help with the data volume problem, as Gnucash's present
design requires the entire dataset be loaded into memory.

What do you think are advantages of having the entire data set in memory?
("in memory data store" is an oxymoron for current computer design). Bear in
mind that archiving part of the dataset means that it's no longer in memory,
so it's really a hack to reduce memory use for a program that can't deal
with as-needed retrieval.

Regards,
John Ralls