On Thursday 26 October 2006 10:49, Ivars Grinbergs wrote: > Derek Atkins wrote: > > "Daniel Espinosa" <[EMAIL PROTECTED]> 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. _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
