Code Set pattern or best practice?

Question

Hi all,
I have what I would have thought to be a common problem: the best way to model and implement an organization's code sets. I've Googled, and I've forumed - without success.
The problem domain is this: I'm redeveloping an existing application, which currently represents it's vast array of code sets using a seperate table for each set. There are currently 180+ of these tables. Not a very elegant approach at present. The majority of these code sets are what I would class as "simple" - a numeric value associated with a textual description - eg 1 = male, 2 = female, or 1 "drinks excessively", 2 "drinks sometimes" ... etc. Most of these will just be used to associate a value with a combo box selected value.
There are also what I would class as "complex" code sets, which may have 1..n attributes (ie not just a numeric and text value pair). An example of this (not overly complex) is zip code, which has a unique identifier, the zip code itself (which may change - hence the id), a locality description, and a state value.
Is there a "best practice" approach or pattern which outlines the most efficient way of implementing such code sets? I need to consider performance vs the ability to update the code set values, as some of them may change from time to time without notice at the discretion of government departments.
I had considered hard coding, creating classes to represent each one, holding them in xml files, storing in the database etc, but it would seem that making the structure generic enough to cater to varying numbers of attributes and their associated datatypes will be at the cost of performance.
Any suggestions would be greatly appreciated.
Thanks.
Paul C.

Answer 1

Hi Saish,
Thanks for your response. Yes, this approach is what
I had considered - I'll be using Hibernate so these
values will be cached etc.
I guess my main concern is reducing the huge number
of very small tables in use. I was thinking about
this some more, and for the simple tables was
thinking of 2 tables: 1 (eg "CODE_SET") to describe
the code set (or ref table etc) in question, the
second to hold the values. This way 80 odd tables
would be reduced to 2. Not sure what's best here -
simpler ER diagram or more performance!Tables...
Enumeration
- EnumerationId
- EnumerationName
- EnumerationAbbreviation
EnumerationValues
- EnumerationId
- ValueIndex
- ValueName
- ValueAbbreviation
The above allows the names to change.
You can add a delete flag if values might be deleted but old records need to be maintianed.
Convention: In the above I specifically name the second table with a plural because it holds a collection of sets (plural) rather than a single set.
In the first table the id is the key. In the second the id and the index are the key. The ids are unique (of course). The enumeration name should be unique in the first table. In the second table the EnumerationId and value name should be unique.
Conversely you might choose to base uniqueness on the abbreviation rather than the name.
The Name vs Abbreviation are used for reporting/display purposes (long name versus short name).
It is likely that for display/report purposes you will have to deal with each of the sets uniquely rather than a group. Ideally (strongly urged) you should create something that autogenerates a java enumeration (specific with 1.5 or general with 1.4) that uses the id values and perhaps the indexes as the values and the names are generated from the abbreviations. This should also generate the database load table for the values. Obviously going forward care must be taken in how this is modified.