Re: Data Constraints AND Application Constraints

From: Paul <paul_at_test.com>
Date: Sat, 19 Mar 2005 08:40:42 +0000
Message-ID: <423be58a$0$18400$ed2e19e4_at_ptn-nntp-reader04.plus.net>


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.

Are we sure that check constraints are meta-data?

They are just propositions, like the rows in tables are, only they are solitary rather then in a set of similar propositions.

I don't think they are propositions about data, but propositions about reality.

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)

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.

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.

Paul. Received on Sat Mar 19 2005 - 09:40:42 CET

Original text of this message