SQL backend for GnuCash 2

[Daniel Espinosa]

2006/10/25, Josh Sled <jsled at asynchronous.org>:
> 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.
>

Of course the efort must be to have working GnuCash database backend,
the other is just an idea turning my mind, but nothing to worry about.
Go to make this to work.

-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (entrámite, pero para los
cuates: LIBRE)