Am Montag, 3. Januar 2011 schrieb John Ralls: > We need to re-think KVP entirely: It doesn't match up very well with the > relational model.
Yes. > The HBCI (online banking) setup, on the other hand, is contained entirely > in a hierarchy of KVPs. This makes some amount of sense in XML, but it's > insane in an RDB. RDBs don't like recursion, and there's no way to do > arbitrary hierarchies without recursion. HBCI needs its own tables. Note that the online banking data storage for sure doesn't have to stay the way it currently is. Storing everying in deeply nested KVP was just the easiest way to add this into the XML format. We can very well refactor this into tables on their own for the SQL backend - it would "just" require a developer who is actually using the online banking and who invests the 3-6 work days to model the data and implement the storage. On the level of the C code, the online banking module needs the data access as available in the following headers: * src/import-export/aqbanking/gnc-ab-kvp.h * src/import-export/aqbanking/gnc-ab-trans-templ.h (and in particular gnc_ab_trans_templ_new_from_kvp and gnc_ab_trans_templ_to_kvp) * src/import-export/import-match-map.h (in particular gnc_imap_create_from_book) I'm just saying the online banking data has no inherent requirement to be stored in KVP. It was just the easiest storage implementation back in XML days, but nowadays we can change the storage just as well. Regards, Christian _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
