Designing For Lookup Values

Question

I am wondering what the protocol is in your development shop or project for dealing with lookup values, such as countries of the world or states in the United States of America.

I have seen it done in two different ways: at one place I worked our lookups were all stored in a database table with the prefix "L_" and had the following columns: id, code, desc, ordersequence. So, for example, for countries of the world we would have a table like:

CREATE TABLE L_Countries(

   CountryID INT IDENTITY(1,1) PRIMARY KEY, 

   CountryCode VARCHAR(10) NOT NULL, 

   CountryDesc VARCHAR(50) NOT NULL, 

   OrderSequence INT NULL

)

More recently I have seen an example where lookups are baked into Enumerations, for example:

enum Countries 
{

  Croatia = 1, 

  Slovenia = 2, 

  Serbia = 3, 

  // and so on  

}

In the event that these are originating from a database table, there is a utility that will generate the C# code for the enumeration. Otherwise someone just takes the time to hardcode all the entries using the assumption that the values are not likely to change. For the numeric values in the enumeration, they are hardcoded based on the ID column in the corresponding lookup table in the database if it exists, or just hardcoded based on entry starting from 1.

The argument for the former approach which, admittedly, I favor, is that it is quite flexible giving the option for using codes or full descriptions, manipulating order, and making changes without having to recompile. Although the option to generate code from them is possible, a big advantage is that they remain true "lookups" when relegated to the database. Finally, the way they can be used is flexible: as values in a Dictionary collection or generating ASP.NET ListItems or html combobox elements with server side code.

Arguments I have heard for the latter is that values will not change, and that there is overhead in having to retrieve lookup values from the database even if they are cached at the application level. By hardcoding them or generating an Enum, they are available without the penalty of database retrieval.

My questions are as follows:

1. Which option makes more sense to you or, if your answer is "it depends," can you give a scenario where the hardcoded enumerations are better than a database lookup across an entire application?

2. Are there other ways that you have seen which are an elegant solution to dealing with lookups? I have worked on an application where there was a single table for all the lookups (it included a "lookupname" column) as an example. How does your alternate approach compare to the above two approaches?

Answer 1

If the information is very static and used for flow control, etc. I would use an enum (i.e. we use them for medical form types, various options on medical forms, etc.)

If the information is static but larger, or if no value or expressiveness would be offered by making it an enum, and it is not needed for joins, etc. we store it in XML or a hashtable and read it in as needed and/or embed the resource.

If the information is going to be used in database joins, is excessively large, or if it is simply more practical to store it in a database lookup table, we do so, generally with an int as a primary key.

Hope that helps

Answer 2

These approaches are not mutually exclusive. I used CodeDom to autogenerate the enum code from the database table. There is a bootstrap issue (i.e. how do you populate and manage the database itself), but you could generate the enum in a build step, thereby ensuring that the two never get out of sync.

Answer 3

The ISO standard for country codes is either 2 or 3 characters. The ISO standard for country names is 40 characters. ISO also specifies numeric identifiers for all countries.

I see no point in using IDENTITY as a key in this table because the values apparently need to be generated at design time for the ENUM and not inserted at runtime. Unless it is being used somehow then I suggest you drop the IDENTITY property and also make the country code unique. As it stands the design is weak from a data integrity perspective because it lacks a natural key.