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

This is a question about database design philosophy and opinion more than anything else.

Imagine we have a person table

ID (int), Title(VARCHAR(22)), Gender(Char(1)), State(Char(2)), First_Name..........

Something along those lines.

Now, we all know that it makes no sense to have a gender table - a simple check constraint = 'M' or 'F' is all that's required.

For Title, the situation is slightly different. You could have Ms., Mr., Mrs. - but what happens if you want to add 'Fr.', 'Col.', 'Excellency', 'Her Imperial Highness', 'His Holiness'? All, of course in the knowledge that you would never have more than 20-25 entries in the Title field.

What's better in this case?

To create a table called Person_Title and develop a user screen to maintain it (adding one record every year or so, and then very few for years), or to permit in these circumstances the maintainer of the tables to issue DDL against the Person table and add to the check_constraint clause (said maintainance being done at night or something like that). What about indexes on this table - IOT?

Bitmap index on the Person_Table on the Gender field?

Assuming the State field has the American States - say 50 - 55 entries which are unlikely to change - which is better - a long check constraint or a referencing table?

Where does one start drawing the line between check constraints and tables - i.e. the maintainance and verification of Foreign Keys?

Any ideas, discussions, URL's, references or other stuff welcome.

Paul...

-- 

plinehan __at__ yahoo __dot__ __com__

XP Pro, SP 2, 

Oracle, 9.2.0.1.0 (Enterprise Ed.)
Interbase 6.0.1.0;

When asking database related questions, please give other posters 
some clues, like operating system, version of db being used and DDL.
The exact text and/or number of error messages is useful (!= "it didn't work!").
Thanks.
 
Furthermore, as a courtesy to those who spend 
time analysing and attempting to help, please 
do not top post.