Re: Data Constraints AND Application Constraints

Paul wrote:

> Kenneth Downs wrote:

>> I'd love to discuss the shape of that rules engine with you, and the
>> method of implementation.
>> 
>> For instance, it seems to me that Declarative Rules == Data Dictionary.
>> Meaning a body of declarative statements is essentially a series of
>> propositions about data.  Or as we like to say, it is meta-data.  So it
>> seems the real question is, what is the structure of the meta-data
>> tables? The answer to that question determines the capabilities of your
>> engine.

As David points out, we risk a definition pothole here.

The database is a record-keeping system. We want the records to be as accurate as possible.

But arguments about reality can be a distraction. The system records what it is told. Constraints allow it to reject information that cannot be true and automation can ease the jobs of people, but ultimately the database holds only what it was told, not what is real.

>
> Some constraints could possibly be encoded as either data or meta-data,
> for example:
>
> [data] "A person's age must be between 0 and 255"
> [meta-data] "A person's age is stored as a single-byte unsigned integer"
>
> but then the latter is more of a implementation detail than a
> constraint. Though I guess it creates an implicit logical constraint
> (i.e. the former one)

In this particular case the record-keeping we are doing is the person's date of birth. Given that a person's age is computed with reference to any particular time, usually the transaction date, experience suggests three digits of precision is enough. End of story and we move on.

>
> So is there a need to store these constraints in tables? The only reason
> we store "normal" propositions in tables is because there may be several
> of them all fitting the same predicate pattern.

See my reply to David. We store the complete specification of the system. It allows the following actions to be computerized:

1. Generation of database
2. Generation of client-side code
3. Generation of nifty HTML specification, complete with signature line for client :)
4. Generation of diff reports, to explain to pesky head of IT what will happen when we upgrade his database, complete with signature line
5. Automation of testing, which reads spec and issues db commands to see if comes out the way it is supposed to.

>
> Hmm, so maybe although constraints are data, we could jump up a level
> and store the meta-data about the lexical structure of the constraints
> in a table? Maybe by grouping constraints into simple categories like
> "foreign key constraint" etc? But choosing these categories is pragmatic
> rather than for any deep reason and doesn't allow for arbitrary
> constraints. Just some thoughts anyway.

We actually do not want arbitrary constraints as such. We want a small set of primitives that, by composition, can make up constraints of arbitrary complexity and intent. We have found the following to suffice:

1. Primary key
2. Foreign key
3. Extended types, such as Range types, with suiable definitions of primary and foreign keys for them.
4. Automations, calculated data (there are 4 types that allow for anything)
5. If automated data is materialized, it must be protected from user writes
6. Comparisons. A <= B or A<= constant.

Points 3 and 4 allows all constraints to be either entitity, referential, or comparative. This "RISC" strategy has really begun to pay off for us.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)