parent accounts, groups, and classes

[Dave Peticolas]

David Merrill writes:
> In light of the discussions we have been having over whether the
> account group mechanism should be strictly hierarchical or whether an
> account should be allowed to exist within more than one group, I am
> considering providing both capabilities in the database.
> 
> First, the group table would define groups. Each group would
> contain arbitrary accounts, and accounts can belong to more than one
> group via a third table, account_group.
> 
> Second, the class table would define classes. Each class would contain
> arbitrary accounts, but an account can belong to one and only one
> class. Possibly, every account must belong to one class or another.
> 
> These are implemented independently of the GUI, so the GUI can make
> use of either or both of these mechanisms as it sees fit. It is easy
> enough for me to do both rather than choose one.
> 
> Regarding the parent account mechanism, can someone please explain to
> me what this does for us that the account group mechanism above
> doesn't? Are we actually using the account "tree" that it results in,
> or just using it as another way to group accounts, where the top level
> account is a dummy account?

I'm not sure what you mean here. In the engine, the parent account
mechanism is the group mechanism. There is no other way to specify
subaccounts other than through groups.

dave