Managing DB reference data and it's related code

Question

Reference Data, or lookup tables are things like CustomerType, ProductType and so on. They change infrequently, occasionally a new type is added or an old one retired. In code they're often reproduced as enums/constants, and also used to populate combo boxes. Adding a new Type shouldn't break existing applications, and more often than not those new types are only required to support a feature of a new application, the legacy app(s) should ignore it.

This situation will be familiar in most dev shops, after a few years/months it's messy, uncontrolled and, if the DB and code gets out of step, bad things happen.

How do others manage this issue? What does the code/DB look like, and how is it versioned?

Answer 1

Do you mean, that IDs and labels are hard-coded in the code, and appear in a look-up table in the database as well?

The approach we've taken is to read the 'type' IDs and labels from the database and use them to populate list boxes.

(Fortunately) I've not had to support different versions of an application that need to read different sets of values from the same look-up table.

I've heard of people assigning minimum version IDs to look-up table values. The application passes in its version (1.5 maybe), and retrieves all look-up values with a version 1.5 or less. Look-up values added for a later version of the application (e.g. 2.1) would be ignored.

This obviously introduces some significant maintenance overhead.