RE: Check constraints was: Imbedded SQL vs Sequence object

From: Buck

I have a somewhat different view yet. Using a constraint at the DB
level means that the optimiser knows more about your database.

Yup, I buy this. That's why I think using the DB to specify relationships
is a good idea. And maybe things like uniqueness.

And I guess carrying the idea forward, maybe telling the database that a
field can have only two values can tell it to build an EVI over that field.
Possibly. Although one would hope that as optimizers get more intelligent
they would get that information from database statistics.

Your
documentation tooling knows more about your database... Is there a
current, practical upshot? Beats me. At least in the future, the
optimiser might be able to make use of RI. It certainly won't make use
of an HLL trigger. Neither will documentation type tooling.

Using your constraints to document your database seems a bit of a stretch.
I can see pros and cons. Having to drop and recreate your constraints every
time you add a new department code might be an issue. Then again, the
argument would be that if it's a fairly dynamic field, it should have its
own definition table. Aiiiiiieeeeeeee. My head hurts on that one.

Not sure that added much to the discussion but I know that when I
personally start saying something like 'one more thing to look at?' I
try to reexamine my motivation for thinking that way. Because
externalising my logic has been most helpful. A bit more complex, but
on the whole, better.

Yeah, but externalizing the logic into a well-documented server is just as
good. Make sure you comment it in such a way that your comments can be
extracted and you can document it better than any constraints. Of course,
that means keeping your comments up to date, but that's a different issue
<grin>.

Joe