Budgets ... again

[Derek Atkins]

Wm Tarr <wm.tarr at gmail.com> writes:

> On 2011-09-18 15:17, Frank H. Ellenberger wrote:
>> Hi,
>>
>> Am Montag, 12. September 2011 um 03:24:30 schrieb Wm Tarr:
>> :
>>> Extracting data from an SQL backend is much cleaner and just involves
>>> one sql script.  Essentially what it does is "normalise" GnuCash's
>>> sometimes obscure tables into ones that humans can easily understand,
>>> i.e. accounts become viewable as accounts, transactions become viewable
>>> as transactions, etc.
>> Just for couriosity: where is the normalization broken - with exception of
>> the "For backward compatibility use slots for new features" rule?
> Using the slots suggests bad design higher up the thinking process of
> the db design.  I am not here just to be a critic, Frank.  I *like*
> GnuCash.

A lot of it is historic.  GnuCash's primary storage is still the XML
datafile, written all at once.  And, historically, they used these slots
tables (Key-Value Pairs) as an extensibility mechanism so that you could
add new data features in a backwards-compatible way.  This way an older
version of gnucash could read your data file and write it out without
losing data.  Whereas if you added a new XML tag, older versions of
gnucash wouldn't know how to read it, and even if it just ignored it
when you rewrote out the data your new tag would be completely lost.

With the migration to SQL, the initial method was to use SQL purely as
another data store.  Internally the data remains exactly the same.  The
benefits of using SQL are:

1) You can commit each transaction as its entered (no data loss due to
   an application crash or system shutdown without saving).

2) Theoretically you could start gnucash without reading all the data
   (although this is still only theoretical -- it's not implemented
   now).

EVENTUALLY we could make the SQL backend "primary", make XML an
import/export sharing format, and at that point we could normalize the
data.  But we're not there yet.  XML is still primary, and unfortunately
the data is particularly tied to the storage.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available