SQL backend for GnuCash 2

[Ivars Grinbergs]

Derek Atkins wrote:
> "Daniel Espinosa" <esodan at gmail.com> writes:
>
>   
>>> 1) We don't need an AccountType table.  AccountTypes are not data,
>>>    they are encoded in the application.  There's no reason to add
>>>    them to the database because they are constants.
>>>
>>>       
>> If usefull if you want a strong data integrity done by the Database
>> server, and if you want to share with others programs (I plan to
>> develop some one for the desktop)
>>     
>
> You can't get enough data integrity from the database.  For example,
> you cannot define the database in a way to enforce balanced transactions.
>
>   
Theoretically, it is possible by means of triggers and stored 
procedures. But I'm not sure that many DB engines support them and if 
support, then in different ways and at different degree. Therefore I 
don't think it is worth to bring existing logic (that checks and 
enforces certain integrity) from application tier (single point) to DB 
backend tier (potentially many different  implementations  for different 
backends).
> If you prefer, feel free to make the "account type" an "enum".  But I
> still think an 'integer' is sufficient; gnucash already knows what the
> account types are.  Keep in mind that there are LOTS of these "enum"
> types all throughout the code.
>
>   
For "enum" enforcement at DB level there are CHECK CONSTRAINTs in 
standard SQL. Of course, those will not give meanings of "integer" 
values, but to solve this, there is option to define VIEWs in SQL.


Ivars