在我的应用数据库中，某些列只能有2-4个可能的值。
例如
“GENDER”只能有2个值（'男'，'女'）
“婚姻状况”可以有3个值（“单身”，“已婚”，“离婚”）
“PROC_STATUS”可以有3个值（'待定'，'进行中'，'已完成'）
“PROC_SATISFACTION”可以有值（'令人失望'，'不满意'，'满意'，'非常满意'）
还有一些像这样的主数据值。
将此主数据存储在数据库中的最佳方法是什么？
为每个人制作表格似乎不是一个好选择，因为数据是静态的（几乎不会改变）而且非常少。
另一个选择是使用Check Constraints。
另一种选择是在代码中创建枚举。
我正在寻找一种将这种主数据存储在DB中的方法。 Ia musing SQL Server 2012。
任何帮助都将受到高度赞赏。
答案 0 :(得分：1)
来自系统分析师......
主要考虑因素是您是否要进行任何国际化。在您认为许多语言不是基于拉丁语的情况之前，性别似乎非常简单'M'和'F'。
另一个考虑因素是，数据库是否真正打算作为完全独立于应用程序的关系数据库运行（用于第三方报告，数据导入和导出等），或者数据库只是应用程序存储。
IMX，如果您不需要国际化，那么对于性别问题，我会使用char(1)和'M'的{{1}}字段。除此之外不需要任何东西，因为对于这样的类别它是相当明显的（除非你的系统需要担心复杂的性别等）。同样，如果您可以使用'F'或'Y'获取真/假字段，并且不想使用'N'，那就没问题了。在整个申请过程中保持一致。不要混合搭配。
对于其他所有内容，我会创建一个验证表，其中包含代码，代码的描述/扩展以及（如果可能的话）Active列，以便用户可以指定不再使用某些代码（确保您的代码尊重！）。在复杂系统中，应用程序的系统设置区域允许具有SysAdmin访问权限的用户创建新代码，将其标记为活动或非活动，或者在未使用时从验证表中删除代码。例如，他们可能想要PROC_STATUS为Cancelled，或者PROC_SATISFACTION为＆＃34; No Response＆＃34;。外键约束很好，但许多使用此方法的应用程序根据我的经验不使用FK。
如果您的应用程序需要拥有i18n并且数据需要在不同地区之间移植（例如，德国的数据库需要能够干净地连接到中国的应用程序服务器，只需要几个更新语言更改）然后您无法将代码存储在基表中。您可能需要使用映射回验证表的整数，其中您具有查找ID整数，用户将用于其区域的代码，该代码的长名称，然后是活动/非活动选项。正确的i18n将包括使用正确的值预先填充这些表，具体取决于安装。