Re: When to use check constraints and when to use small tables?

> If you think the # of values is going to change, or the values are
> going to alter, and you don't want to have to change the app or the
> check constraints: put them in a table.

Well, what I was asking was when it is appropriate to change the app by modifying check constraints on a table - is the rule about no DDL in an application an *_ABSOLUTE_* one, and if not, what are the circumstances under which it should be allowed?

> If the number of values is more than 3: always put them in a table.
> You might forget a state or miscount them.

Ah, I see. This is a perspective I had forgotten about when framing my original post - I forgot to think about those application programmers for example who will have to write reports on the data in the app - it's true enough that anything beyond two or three is probably too much - I mean gender is OK but what about title?

The part of my post which hasn't been addressed is what sort of indexes to put on the Person table - i.e. a bitmap index if it's only two values - what about higher numbers - what's the rule of thumb for the cardinality of bitmap indexes?

Also, the construction of these "minor" tables - should they be indexed, and if so, what sort of index should be used - and if there are differences, why?

Paul... Received on Thu May 25 2006 - 02:15:25 CDT