If the status really is just an attribute of the main item rather than a separate entity that is related to it, the restriction on the set of values is a domain constraint; there are two standard ways of implementing domain constraints: (a) as an auxiliary table and a foreign key relationship with the main table pointing to the auxiliary table; and (b) as a row level check constraint without any auxiliary table (which doesn't call any UDFs which reference any data other than attributes in the row which are passed to them as parameters and literal constants held in the UDF's definition, which is a single statement). Method (a) is the used only when it's needed because the size of the attribute is bigger than the reference to a row in an auxiliary table, and putting the data in the main table would increase the row size enough to cause performance problem, since method (a) was is aimed at expressing entity relationships not at specifying attributes of an entity; method (b) is the norm. I think it's probably not a good idea to invent a hybrid, where you are implementing a domain constraint by an auxiliary table accessed through a check constraint. I wouldn't go as far as Gail and say use method (a) definitely, because you've said that tinyint is more appropriate than varchar(20) and I suspect that you probably have only half a dozen possible values, so it's going to be trivial to write an appropriate check constraint using no UDF at all and no auxiliary table (and you can index the main table on that attribute too, it's quite likely that you'll need to for performance). But I agree completely when she says in effect that trying to design optimisations too early is not a good approach - implement one of the standard approaches, if it doesn't perform try the other, and only when that also doesn't perform try to optimise by doing something new. That wouldn't have been good advice 33 years ago, when there was very little knowledge of good structures and algorithms built from experience in RDBMS, but a third of a century on there is a lot of history to learn from and well established standard practise to follow when there's no good reason not to. Maybe that would not be good advice in a research situation either, but I don't imagine that's where you are.