gnucash-1.8.0 and Postgres Back

[Matthew Vanecek]

On Tue, 2003-02-04 at 18:03, Laurent Duperval wrote:
> On  4 Feb, Derek Atkins wrote:
> > Hi,
> > 
> >> I am interested in using backend postgresql. Where can I find any howto or sth.?
> > 
> 
> Does this speed thing up or slow things down? Other than having a
> database to hold the data, what are the advantages of the SQL backend
> over the XML file?

It depends. ;)

Having an SQL back-end is an excellent option for businesses and other
multi-user environments.  It provides for enforced integrity of data and
easy concurrent access.  You (should) have the option of how much data
you want to actually *load* from the data store.   i.e., you can just
load a certain range of Splits or Transactions based on your
configuration.  A database solution is quite a bit easier to divide
across accounting periods (from a development perspective).

For a single user perspective, the win comes when you have a 10MB file
vs. a database data store.  The data from a database is loaded as
needed.  An XML file, however, must be loaded in it's entirety before
it's available.  That's because it's a single "document", and the XML
must be parsed.  This is one of the reasons there has been so much talk
about using a separate file for each accounting period.

The main disadvantage *today* is that the Postgresql backend development
has not kept pace with the rest of Gnucash.  Therefore, certain features
(namely, all the new features in 1.8.0) are not supported.  You still
have the same capabilities as in 1.6.8, re types of data/accounts that
can be handled.  This will change, however.  Hopefully sometime in Q2
I'll have something ready for mass testing.  Depends on how much life
intervenes. :)

One thing that has been mentioned is embedding the SQL server into
back-end.  This will provide the advantages of an RDBMS and the
convenience of not having to administer a database.  MySQL supports
embedded servers.  I'm not sure about Postgresql.  Accordingly, my
current design principles are to make the SQL back-end as standards
compliant and portable as possible.

If you're adventurous, or just want to provide feedback, we certainly
encourage use of the SQL back-end.  If you're trying to run a business,
you may want to wait a while.

-- 
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...