On Sat, Oct 18, 2014 at 12:45 PM, Wm... <[email protected]> wrote:
> Thu, 2 Oct 2014 23:37:09 <CAK21+hMx7wgt0imEtHp_WTFuYaqLTPJ+OwFHM+wjPS_ > [email protected]> > Martin Blais <[email protected]> wrote... > > [not sub'd to hledger so dropped from ng list] > > It's always important to me to state the reasons why this is not possible >> as a regular table: filtering has to be operable on complete transactions >> (with all legs), and operations on inventories of commodities have to be >> possible. These are the reasons that we cannot just spit out the data to >> some SQLite table and then use that (I'd like to see someone argue the >> opposite). >> > > Given that you seem to write your thoughts out I've missed the doc where > you say what the reasons are it can't be done in SQLite (or postgres or > mysql) tables. Bear in mind that GnuCash uses any of the 3 mentioned dbs > as storage methods alongside XML (cf plain text file). > I'm not so much interested in the storage method; a relational database of XML can represent the internals of Beancount alright, that's easy, the issue is making simple queries on tree-structured data that produces reports suitable for accounting, with operations on inventories of positions. > > Your own recently mentioned implementation (bean-sql) creates multiple > tables but it could actually be done in one table if you simply regard > SQLite3 (the overhead and fuss to new users mitigates against the others) > as a very efficient storage method and just take it from there. > No you can't. How would you represent the two-level tree structure of "transactions <- 1:N -> postings" with - a single relational table, and - no duplication (otherwise it's a derived form and not suitable for representation) ? If you have multiple tables, you end up having to do joins and deduplication. With a single table, you have duplication of information. At the moment I output separate tables for transactions and postings, which can be joined, but it still doesn't allow you to make great queries that involve the kind of filtering that is convenient for generating, e.g. balance sheets. The Beancount Query Language will specifically address these issues by: - allowing filtering to occur at two levels in a single query: * filtering at the entries level (with predicates on postings allowed), plus * filtering at the postings level - support inventory arithmetic and aggregation functions on inventory objects and rendering functions (e.g., COST()). - support flattening of multiple lots (to produce lists of holdings each with their cost basis) - explicitly support the "close" operation as syntax, that inserts transactions to clear income statement accounts to equity and removes past history I claim that with the features above you can explicitly model all the queries being done in Ledger, HLedger and Beancount. > > Within a few minutes you will start seeing your data and wanting to make > some impression on it like "I want to put the transaction and transaction > lines seperately" ... which is what you did :) I don't understand this sentence. > > > > -- > Wm... > > -- > You received this message because you are subscribed to the Google Groups > "Beancount" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/beancount/tLKufVTCdqQUFwvv%40tarrcity.demon.co.uk. > > For more options, visit https://groups.google.com/d/optout. > -- --- 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.
