WHY use anything other than an XML backend?

[John Ralls]

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