DB design document

[Rob Browning]

Jean-David Beyer <jdbeyer@exit109.com> writes:

> I just looked at it and it just showed me how much I do not know
> about double-entry bookkeeping. I am familiar with the Quicken model
> (if I may call it that), and have no predisposition to it. But the
> GnuCash model requires a different mind set. Is there any way to get
> up to speed on this? Books, on-line documentation (other than
> examining source code), etc.? I assume so, but pointers would be
> appreciated.

The docs have some info, but the biggest difference to realize is that
with double entry accounting, you have a "law of conservation of
value".  Basically, value always comes from somewhere and goes to
somewhere.  If you take 100 from cash, it has to go somewhere, to some
other account: savings, food, rent, whatever.  What would be a
category in quicken which is mostly just like a label or keyword
marking a transaction, in gnucash is actually a full-blown real
account.  So, if you're so inclined, you can open up your "Food"
account and see every transaction you've ever made that related to
food.

> I suppose one way would be to play around with an existing
> distribution of GnuCash. I tried that some months ago, but could not
> successfully import my Quicken stuff. Probably lack of
> understanding, but possibly I picked up a development version
> instead of a "stable" one. Any recommendations on a version to try?
> I run Red Hat Linux 6.0 with a lot of RPMs applied. E.g., I have
> glibc-2.1.3-21.

Though I don't use it, Bill's apparently done a stellar job of
reworking the QIF importer -- no mean feat that, given the horrendous
ambiguity in their format -- so in more recent versions, you should
notice much better results.

The most interesting version these days is the latest CVS version, but
it's guaranteed to corrupt your data.  For my finances, I use a CVS
version from a couple of months ago, before we put in the new XML IO
code, and it seems fine.  So for experimentation, and if you want to
see the latest features, of which there are many :>, you can use the
latest CVS, but for anything else, pick something older.

> It looks so to me. I know that the DBMSs with which I am familiar
> each try to do their own, and in their own ways. Almost certainly
> not compatible. So if GnuCash wants to enforce yet another policy,
> it will need a way to either use the underlying tools of the dbms,
> or find a way to get around them.

At this point, as I've said, I now tend to think that we should just
plan to handle encryption/authentication directly by having a
server-side gnucash daemon.

> Or all communications between client and server?

This is all I've ever been talking about.  AFAIK no one's been
planning to use an encrypted DB.  Frankly, if you want that, you'd
probably be better off just using an encrypted filesystem.


> But even if one could, in confidence, pick one dbms and adopt it
> without reservation, the discipline of building an API to separate
> it from the rest of the application generally results in a cleaner,
> more maintainable system.

Agreed.

Thanks again for all the input.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930