Re: database integrity

Kenneth Downs wrote:
> mountain man wrote:
> > As an aside ... do you think that one may ever validly
> > consider a database to be *more* that a record
> > keeping system?
>
> Well, if you are asking me, no. There is a thread from a few days
> "Modelling considered harmful" where I tried to spin out the position
that
> because they "mere" record keeping systems, we should not dress them
up by
> describing them as "models" of reality.

I thought that thread "concluded" by referring to a database in two ways: one as a set of propositions (which you said could be a model), one as a set of records (which you said aren't a model). The problem in this sort of argument is the use of the terms "model", "mere" and "record keeping," all of which are loaded and problematic.

> If the fact was true when committed, a change in rules cannot falsify
it.
> If I bought a widget with no VAT before VAT existed, then VAT comes
into
> play, the record of my prior purchase must be valid.

Agreed - a fact is a fact.

> Hmmmm. In a prior life I built a system that checked for constraints
before
> they were applied, to detect failures. This was necessary because of
the
> assumption that a change in constraints would apply to old data.
>
> It was in doing this that it occurred to me that constraints
developed over
> time should most likely apply only to data moving forward. The
exception
> was a bug fix where you wanted to fix bad data, leading to the
conclusion
> that both options should be supported.
>
> Now the real trick question is, how do you build constraints that
apply only
> to new data?

I'm not sure the terms "old" and "new" are valid. "Old data" is a set of facts, as is "new data." The database predicates and constraints govern what can be recorded. This immediately suggests different sets of relations when rules change; otherwise, what meaning would a query over a relation containing "old" and "new" data have?

Of course, the degenerate case is one where the constraints include date/time clauses, such as "(today<3/3/04 => something) && (today>=3/3/04 => something else)". However, I'm having trouble thinking of good examples.

In short, the above discussion would lead me naturally to "history" versus "control" tables, which I tend to see in apps anyway.

• Eric