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 <[EMAIL PROTECTED]>: > > > 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 [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
