DB design document

[Dave Peticolas]

David Merrill writes:
> Please take a look at the latest revision of my design document and
> give me some feedback.
> 
> Some of the issues I'm dealing with:
> 
> 1. Architecture: A big, fuzzy cloud right now.
> 2. Security: Lots of questions, few answers. Among the questions,
> encryption over the wire, locking down the db itself (depends on the
> db), and managing user permissions on some kind of capabilities model
> tbd.
> 3. Table Schemas: Gaping holes.
> I have quite a few questions about various fields that are marked with
> question marks in the design document. Would you please take  look at
> it and give me some feedback?

security: units of what is currently called 'damount' in splits
          that belong to this account

currency: units of 'value' in splits that belong to this account

Neither currency or security should be stored as 3-character codes.
They should be references to entries in the commodities table.

security_scu & currency_scu: 'scu' is Smallest Convertable (I think)
  Unit, the denominator used for amounts in security/currency.
  Commodities have default scu's, but accounts can override them.
  For example, you might have stock in two different brokerages.
  One may track your shares to 4 decimal places, and another to
  5 decimal places, even if they're the same shares. This is not
  an academic example.

Note: we've considered moving currency to transactions. This may
      still happen in the future.

dave