SQL backend for GnuCash 2

[Benoit Gregoire]

On Thursday 26 October 2006 10:49, Ivars Grinbergs wrote:
> 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).

Perfectly true, but that's not e reasaon to designe our schema to make it more 
difficult thatn it can be.
 
> > 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.

Enums are NOT standard SQL.