在数据库中维护与客户端软件枚举匹配的 id答案

【问题标题】：maintaining ids in database that match client software enumerations在数据库中维护与客户端软件枚举匹配的 id
【发布时间】：2008-11-20 22:41:52
【问题描述】：

假设我在一个名为 TransactionType 的 sql server 2000 数据库中有一个表：

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]

然后我有一个事务表，其中有一个名为 TransactionTypeID 的列，与 TransactionType 表的 ID 列无关。

我的 .net 客户端应用程序负责插入交易记录并指定交易类型。我的第一个想法是定义一个枚举，将枚举转换为整数并将该值传递给数据库。问题在于，有人可能会进入数据库并更改 TransactionType 表中的一个 ID，从而使数据库中的 ID 与客户端应用程序枚举中的 ID 不同步。

那么，在我冗长的解释之后，我的问题是，是否有其他人用来解决这个问题的设计模式/技术？

【问题讨论】：

标签： .net sql-server

【解决方案1】：

您可以考虑使用与子表松散绑定（未强制执行）的编码系统。假设它是一种颜色，您的子表可能如下所示。

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

现在您有了一个 ID，如果您在没有加入的情况下显示，它对人类非常有用，如果您需要更准确/详细的“名称”值，您可以加入或检索它。所以很明显，当您查看父条目（假设它是水果）时，您不需要执行连接。另外，更改 ID 从来都不是很好的理由

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

请记住，如果您计划添加大量子类型，则不应使用此系统，但如果您只有一打，它可能是一个不错的捷径。如果您计划拥有大量“水果”，这也不是一个好主意，因为 CHAR/VARCHAR 不是存储数据的有效方法。但是对于 99% 的数据库来说，这种方法就可以了。

【讨论】：