SQL backend for GnuCash 2

[Josh Sled]

On Wed, 2006-10-25 at 14:52 -0500, Daniel Espinosa wrote:
> Let me study this items, but at first, I could say that the way
> GnuCash handles the numeric values and representation, could be out
> the scope of the schema becouse it will show how the values are stored
> in the database and how they are related with others. 

Well, to some degree ... e.g., we shouldn't try to pack a gnc_numeric
structure into a blob or anything.  But we shouldn't try to get around
representing a gnc_numeric, either.  Speaking of which...

Values in GnuCash are generally represented as a rational value,
represented by a numerator and denominator, each a 64bit integer.  This
GncNumeric is coupled with a specific commodity, usually implicitly,
from the Account of the Split that the GncNumeric value is part of.
That makes them able to store both currency (123.45 USD) as well as
stocks and mutual funds (7.429 shares of fund XYZ).  There's a bit more
detail than that, but that's the core part.


On Wed, 2006-10-25 at 16:14 -0400, Derek Atkins wrote: 
> Quoting Daniel Espinosa <esodan at gmail.com>:
> 
> > Consider that may in the future GnuCash and KMyMoney, could share the
> > same DB and give diferent GUI, why don't work together and define a
> > solid DB storage structure for the end user (and leave him to use the
> > GUI he wants, even a web one).
> 
> I don't think this is a reasonable goal.  If it happens to work out this
> way, great, but I don't think this is a requirement of a new SQL backend.
> 
> Gnucash has very different needs than KMM or SQL-Ledger or any of the other
> apps out there.  I don't think we can share a DB schema easily, and I'd
> rather spend the time getting it working /well/ then working hard to
> try to make something interoperable at the expense of complexity or
> performance (or both!)

I strongly agree with Derek, here.

This effort should be very specifically a database backend for the
GnuCash application, not a generic financial data schema.  I don't have
any interest collaborating on an effort that seeks to be the latter,
especially at the expense of the former.

As well, I don't think it's reasonable for an application's database to
be a *general* point of integration.  Reporting, or read-only
integration, perhaps.  But external insertions against an application's
database should be regarded as kludges, not viable integration
strategies.  The application -- in concert with the database -- is
responsible for enforcing application data constraints.  There are some
that the database can help enforce, and some that it can't.  As such,
integration is best supported at the application level, not underneath
it.

-- 
...jsled
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20061025/5d4faea5/attachment.bin