Proper use of a Lookup table and adaptations for NET

Question

Hello,
I need to create a few lookup tables and I often see the following:
create table Languages
Id int identity not null primary key (Id),
Code nvarchar (4) not null,
Description nvarchar (120) not null,
create table Posts
Id int identity not null primary key (Id),
LanguageId int not null,
Title nvarchar (400) not null,
insert into Languages (Id, Code, Description)
values (1, "en", "English");
This way I am localizing Posts with language id ...
IMHO, this is not the best scheme for Languages table because in a Lookup table the PK should be meaningful, right?
So instead I would use the following:
create table Languages
Code nvarchar (4) not null primary key (Code),
Description nvarchar (120) not null,
create table Posts
Id int identity not null primary key (Id),
LanguageCode nvarchar (4) not null,
Title nvarchar (400) not null,
insert into Languages (Code, Description)
values ("en", "English");
The NET applications usually use language code so this way I can get a Post in English without using a Join.
And with this approach I am also maintaining the database data integrity ...
This could be applied to Genders table with codes "M", "F", countries table, transaction types table (should I?), ...
However I think it is common to use int as PK in lookup tables because it is easier to map to ENUMS.
And know it is even possible to map to Flag Enums so have a Many to Many relationship in an ENUM.
That helps in NET code but in fact has limitations. A Languages table could never be mapped to a FLags Enum ...
... An flags enum can't have more than 64 items (Int64) because the keys must be a power of two.
A SOLUTION
I decided to find an approach that enforces database data integrity and still makes possible to use enums so I tried:
create table Languages
Code nvarchar (4) not null primary key (Code),
Key int not null,
Description nvarchar (120) not null,
create table Posts
Id int identity not null primary key (Id),
LanguageCode nvarchar (4) not null,
Title nvarchar (400) not null,
insert into Languages (Code, Key, Description)
values ("en", 1, "English");
With this approach I have a meaningfully Language code, I avoid joins and I can create an enum by parsing the Key:
public enum LanguageEnum {
[Code("en")
English = 1
I can even preserve the code in an attribute. Or I can switch the code and description ...
What about Flag enums? Well, I will have not Flag enums but I can have List<LanguageEnum> ...
And when using List<LanguageEnum> I do not have the limitation of 64 items ...
To me all this makes sense but would I apply it to a Roles table, or a ProductsCategory table?
In my opinion I would apply only to tables that will rarely change over time ... So:
    Languages, Countries, Genders, ... Any other example?
About the following I am not sure (They are intrinsic to the application):
   PaymentsTypes, UserRoles
And to these I wouldn't apply (They can be managed by a CMS):
   ProductsCategories, ProductsColors
What do you think about my approach for Lookup tables?
Thank You,
Miguel

Answer 1

>>IMHO, this is not the best scheme for Languages table because in a Lookup table the PK should be meaningful, right?<<
Not necessarily. The choice to use, or not to use, a surrogate key in a table is a preference, not a rule. There are pros and cons to either method, but I tend to agree with you. When the values are set as programming terms, I usually use a textual value
for the key. But this is nothing to get hung up over.
Bear in mind however, that this:
    create table Languages
      Id int identity not
null primary key
(Id),     
      Code nvarchar (4)
not null, Description nvarchar
(120) not
null,
is not equivalent to
    create table Languages
      Code nvarchar (4)
not null primary
key (Code),     
      Description nvarchar (120)
not null,
The first table needs a UNIQUE constraint on Code to make these solutions semantically the same. The first table could have the value 'Klingon' in it 20 times while the second only once.
>>However I think it is common to use int as PK in lookup tables because it is easier to map to ENUMS.<<
This was going to be my next point. For that case, I would only change the first table to not have an identity assigned key value, as it would be easier to manage at the same time and manner as the enum.
>>. A Languages table could never be mapped to a FLags Enum ...<<
You could, but I would highly suggest to avoid any values encoded in a bitwise pattern in SQL as much as possible. Rule #1 (First Normal Form) is partially to have 1 value per column. It is how the optimizer thinks, and how it works best.
My rule of thumb for lookup (or I prefer the term  "domain" tables, as really all tables are there to look up values :)), is all data should be self explanatory in the database, through data if at all possible. So if you have a color column,
and it contains the color "Vermillion", and all you will ever need is the name, and you feel like it is good enough to manage in the UI, then great. But bear in mind, the beauty of a table that is there for domain purposes, is that you can then store
the R, G, and B attributes of the vermillion color (254, 73, 2 respectively, based on
http://www.colorcombos.com/colors/FE4902) and you can then use that in coding. Alternate names for the color could be introduce, etc. And if UserRoles are 1, 2, 3, and 42 (I have seen worse), then
definitely add columns. I think you are basically on the right track.
Louis
Without good requirements, my advice is only guesses. Please don't hold it against me if my answer answers my interpretation of your questions.