DB design document

[Bill Gribble]

On Thu, Dec 14, 2000 at 12:47:08PM -0500, David Merrill wrote:
> The security represents the commodity which the account is actually
> measuring, and the currency represents the cash value, IF the security
> is non-cash. It is used to verify we have a balanced transaction.

Right. 

> Can the user and/or admin add to the list of namespaces as well as
> commodities? Could they add a namespace for internal commodities, for
> example a namespace that means "corporate assets", under which they
> have accounts for office furnishings and inventory?

Gnucash is really a single-user program; there's no concept of an
administrator.  I think it's a good idea to talk about the DB stuff as
if it will be multi-user, but the program itself will have to be
substantially changed to support that metaphor.

To answer your question, yes.  ATM the user interface for dealing with
commodities is limited, but if you click on the Currency or Security
'Select' button in an account edit window you can create a new
commodity and a new namespace if you need one.

> So they are not actually defined in the commodities 'database'? There
> are commodities in a commodities 'database', and those are combined
> with the currencies at program load?

I probably should have kept my mouth shut on that, I think I confused
the issue more than necessary.  Currencies live in the same database
as all the other commodities, they are just factored out of the
save/restore process since they are constant.  What happens is that
the currencies are stuffed into the commodity database by gnucash at
program load time, before any files are loaded, and they aren't saved
with the rest of the database in the user's file.  This is just an
implementation detail; when the program is running, they are a part of
the same database as all other commodities.  Be aware that as a non-
database person, I use the term 'database' loosely enough to give
shivers to and possibly confuse people who are into databases :)

> Well this is a good time. As soon as I understand how they work
> together I'll see how it might be achieved in the db.

It probably won't happen before you are finished with your first-round
spec, so don't wait on that.  Just be aware that your database schema
will probably have to change at some point in the future.  My guess is
that it won't be a real holdup given the significant restructuring of
much of the gnucash code that will be necessary to implement a
database backend, anyway.

> It gives me more of an understanding of the problem. I'll have to give
> this one some thought. There seem to be many implications and
> potential pitfalls.

You can say that again :)

b.g.