Database NOT NULLS - ex Diverging applications

[David Tangye <..hidden..>]

On Tue, 2006-09-12 at 22:49 -0700, Chris Travers wrote:

> In some cases, if one forgets to flag accounts for the parts income
> accounts, it is possible to think you are creating a part, when in
> fact that part ends up with a NULL chart id.  When this happens, you
> sell the part that you just created, and the income part of the
> transaction goes into the acc_trans but the chart_id is NULL.  In
> other words, SQL-Ledger says the money went into an *UNKNOWN* account.
> Needless to say, this is very, very bad and if you are running
> SQL-Ledger with such data, your books probably won't balance.  This is
> not merely theoretical either ...
This is a classic data-integrity bug, and should be fixed with highest
priority. Generally the correct fix is to NOT NULL the relevant column.
That's what NOT NULL is for.
Of course it gets back to what I have said before, sorry if its getting
repetitive: its really a question of requirements and modelling.
Specifically 'what is the data in that column meant to represent, in
terms of a relationship or attribute in the logical model?' My guess is
that whatever the answer the column implements a mandatory relationship
or attribute, so must be NOT NULL.

I am fairly sure that there are other places in the current physical
schema that have this same bug. They just haven't led to broken
databases... yet.