On Mon, Jan 4, 2016 at 4:51 AM, Stefano Zacchiroli <[email protected]> wrote:
> On Sun, Jan 03, 2016 at 10:33:32AM -0800, Martin Michlmayr wrote: > > - However, there are some things that belong to a specific person. > > Specifically, I track frequent flyer miles and other reward points > > and for that I created Assets:Rewards:Martin since a) all those > > rewards accounts are for a specific person and b) usually both > > people have the same accounts. > > > > I don't think this scheme is ideal since it's inconsistent > > (Assets:Rewards:Martin vs Assets:Savings:Bank Martin instead of > > Assets:Savings:Martin:Bank) but unfortunately I cannot think of a > > cleaner solution. > > I understand the problem, but I don't think it is specific to the > "spouse account" scenario. It is rather a consequence of the more > general fact that forcing accounts into being a hierarchy is an > artifice. With the exception of the tier 1 accounts that come from > double entry theory (assets/liabilities/equities/etc.), accounts are not > necessarily hierarchical. Rather, they are points in a multi-dimensional > vectorial space. Out of it you can extract several possible hierarchies, > neither of which is satisfactory for all use cases. > That's the right way to look at command-line accounting: the contents of a ledger are really nothing more than a giant stupid table of posting rows. The account is just one particular column in the row. Meta tags are just more implicitly defined columns. Querying implicitly joins the attributes of the transactions to the tables of postings, so you can use them directly. Journals are listings of subsets of rows. Balance sheets and income statements are aggregations where the key is "account". That's it. -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
