SQL backend for GnuCash 2

Benoit Gregoire bock at step.polymtl.ca
Thu Oct 26 16:05:43 EDT 2006


On Thursday 26 October 2006 15:51, Graham Leggett wrote:
> Benoit Gregoire wrote:
> > Yes you can (whith a "real" database).  Checking that the sum of the
> > transaction's splits is 0 it trivial if all splits use the same
> > commodity, and mostly irrelevent if they don't.  That's a really simple
> > stored procedure.
>
> And in the process, you restrict people to using just one "real"
> database, instead of any database convenient to them.

Depends what you use them for.  Stored procedure used for additional 
referential integrity check are not a problem, and saved my ass more time 
than I can count.  Stored procedures that write to the database and actually 
implement business logics operations are (generally) not a very good idea.

> Stored procedures are a double edged sword - very powerful, at the cost
> of database vendor lockin. For a multi platform application like
> Gnucash, vendor lockin makes no sense.

What we need is to come up with a comon data model, and a set of features we 
decide to depend on (ex:  Do we depend on the database supporting cascade of 
DELETE operations?  Transactions (and to what level)?etc.).

That's our baseline, the code will target that baseline (ie:  note depend on 
any behaviour not provided by that baseline).  However the opposite should 
also be true, the code should not depend on specific quiks of that baseline.

Anything above can (and should) be handled for that specific database.


More information about the gnucash-devel mailing list