WHY use anything other than an XML backend?

[John Ralls]

On Apr 20, 2011, at 2:52 PM, Nick Burns wrote:

> 
> 
> 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).
> 
> 
> I've been watching this discussion and just to clarify;  if you are starting out with new , clean,  data on gnucash and you immediately start writing to Postgresql , there should be no problems from what you can see? I would not be doing any banking downloads or imports since all the transactions will be entered manually.  I've started to use Postgresql on the back end already and it seems to work absolutely great.  Transactions are saved right away and any changes or deletions are also reflected correctly in the reports right away.  It seems to just work.  I think for a lot of people with *any* financial program they use it seems that the 'holy grail' is to be able to pull out your data and bring it in to any report writing application to do whatever your requirements may be. This sql back end seems to be the answer to this.

So long as you do no importing of data, you will have no problems with the SQL backend. Even if you do, you will only have the inconvenience of the automatic account matching not working properly unless you manually Save As after doing
an import. No transaction data will be lost.

Regards,
John Ralls