Finding the right terminology for a dictionary table
In my experience with SQL developers, the stronger their background in relational theory, the less likely they are to use terms like "lookup table", "validation table", or "dictionary table".
Instead, they just call them tables. Why?
For you, the important part seems to be tables that
- contain only one text column, or
- contain only one text column and an id number, or
- contain only one text column and a short text code, and
- the primary key is used as the target for foreign key references.
If you think about it for a while, the only thing that distinguishes these tables from others is the number of columns. Relational theory distinguish relations by the number of columns, and I don't feel the need for distinctions like that in SQL, either.
- Every candidate key implements a controlled vocabulary in this sense--the key (and all the other applicable constraints) provide the mechanism that controls the "vocabulary".
- Every candidate key can be used as the target for a foreign key reference, regardless of how many candidate keys a table has, regardless of how many columns a candidate key has, and regardless of whether any of the candidate keys are used as foreign key references today.
- Many such tables only start their life as "lookup" tables. A year down the road, someone discovers the need to store more information. After you add one or two more columns, is it still a "lookup" table, or not?
I often see that list of words as the domain of a function (the set of input values allowed), so I call them Domain Tables. But it´s from a mathematical point of view.
EDIT
See:
As a C coder I'd say that this table looks really like an enum (or enumeration). It exhaustively defines acceptable values and links an automatically given integer to a name (and vice-versa).
And as a SO user I'd say this question really looks a little too open as I don't think there is one unique canonical name...