Re: Translating constraints to RM Terms

> For instance, A is actually a domain, as is B, but the constraint A < B must
> in fact be part of the very definition of the domain A, and here we are
> defining one domain in terms of another. I realized I have not seen this
> disccussed in the year or so I have been a regular here.

These kind of questions are fairly interesting, but the data management field isn't exactly bristling with activity around type systems. For that,
you have to go to the type theorists. They are quite an interesting lot.
Much of what they say goes over my head, but much is also comprehensible.

But I think I must take exception to your claim that we are defining one domain in terms of another. And this rather gets to the heart of a question that's been buzzing around the back of my head for a year or two, namely: just what is the relationship between types and constraints?

And I in fact have a tentative answer, which is that they are, respectively, the compile time and run time behavior of the variables. (Alternatively, the static and dynamic behavior of the variables.)

Consider: the types of the columns of a table are statically identifiable, and for any typed tuple variable whatsoever, we can determine at compile time whether the variable is, say, insert-compatible with the table. (Or whatever other analyses we care to run.)

But what of constraints? Let us consider a foreign key constraint. What can we say at compile time about whether a given insert will be compatible with a foreign key constaint? Exactly nothing, because the success or failure depends on the value of the variables at the time the insert is attempted. We can't know until it's time to try it.

I believe the same thing applies to your a<b constraint. It is not in fact a part of the type at all; it is a constraint on the table variable, which is a distinct thing. If we have a tuple variable and we wish to insert its value into the table, we have to check that a<b at the time of insert. It cannot be done statically. But wait! you say. You could put such a constraint on the tuple variable, and then you could verify it statically. Right! The problem, though, is that you've just pushed back the question one level. Can you push it back all the way? No, because you might be getting values from an external source. If you wanted to read two integers from standard input, you couldn't statically tell that the first was less than the second, so *there has to be a runtime check somewhere.* You might as well put it right where it matters and not try to back-propogate it through the code, as this will only complicate things unnecessarily.

Marshall Received on Mon Jun 06 2005 - 09:27:48 CEST