Splitting the slots table

[Christian Stimming]

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