WHY use anything other than an XML backend?

[Nick Burns]

>
> 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.

-Thanks