maintaining ids in database that match client software enumerations

Question

Lets say I have a table in a sql server 2000 database called TransactionType:

CREATE TABLE [dbo].[TransactionType](
    [ID] [int] NOT NULL,
    [Description] [varchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
 CONSTRAINT [PK_TransactionType] PRIMARY KEY CLUSTERED 
(
    [ID] ASC
) ON [PRIMARY]
) ON [PRIMARY]

I then have a transaction table with a column called TransactionTypeID, keyed off of the ID column of the TransactionType table.

My .net client application is responsible for inserting transaction records and specifying the transaction type. My first thought was to have an enumeration defined, casting the enumeration to an integer and passing that value to the database. The issue is that potentially, someone could go into the database and change one of the IDs in the TransactionType table, making the IDs in the database out of synch with the IDs in the client applications enumeration.

So, after my long winded eplanation, my question is, are there design patterns/techniques others use to combat this issue?

Answer 1

this is a duplicate of http://stackoverflow.com/questions/292378/how-to-avoid-dependencies-between-enum-values-in-code-and-corresponding-values

.. and i didn't really get an answer :)

Answer 2

You might consider using a coding system that's loosely tied (not enforced) to the child table. Lets say it's a color, your child table can look like the following.

ID  | Name
------------
GRN | Green
PURP| Purple
YELL| Yellow
RED | Red

Now you have an ID that if you displayed without a join, is very usable to a human, and if you need a more accurate/detailed "Name" value, you can join or retrieve it. So obviously when you view the parent entry (let's say it's fruit), you don't need to perform the join. Also, there's never a good reason to change the ID

ID | Name   | Color
-----------------
 1 | Banana | YELL
 2 | Apple  | RED
 3 | Cherry | RED

Keep in mind this system should not be used if you plan on adding lots of child types, but if you're only going to have a dozen, it can be a nice shortcut. It's also not a good idea if you plan on having lots of "fruit" because a CHAR/VARCHAR is not an efficient way to WHERE your data. But for 99% of the databases out there, this method will be fine.