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