>>> Rather than using xml data files, which have always seemed odd to me <<<
There are pros and cons to substituting a RDBMS for XML. Since GnuCash was originally designed for an in-memory data store, the XML is it's native persistence system. Over time, it has been altered to substitute a SQL database as the store, but not with a clean relational data model. I have been using GnuCash for both business and personal accounting since 01-Jan-2010, Plus, I imported prior data for long-term investments, etc. So my files are rather large. I've experimented with using SQLite, but not found it advantageous. While it is quicker on the backend (ie. When you quit the program) it is noticeably slower on the frontend. Because it is designed for an in-memory store, it has to load the entire database into memory up front, and that takes more time reading the data from SQLite than simply sucking it in from a flat file. I'm sure that is true with any RDBMS. Another con to using a RDBMS so far as I am concerned is the loss of 'revert' capability. There are occasional situations where it is convenient to simply scrub a session and start over. That's a great deal more complicated restoring a relational database from backup. When I first started using GnuCash, I expected increasing file size to be a problem. I had formerly used Microsoft Money, which had an excellent ability to discard older data without the loss of stuff that needed to be retained long-term. But twelve years on, I've not found that to be a problem. The folks maintaining this software have done a great job of keeping the reading/writing of the XML data store efficient. _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
