1

在我的应用程序数据库中，某些列只能有 2-4 个可能的值。

例如

  1. “性别”只能有 2 个值（“男”、“女”）

  2. “婚姻状况”可以有 3 个值（“单身”、“已婚”、“离婚”）

  3. “PROC_STATUS”可以有 3 个值（'Pending'、'In Progress'、'Finished'）

  4. “PROC_SATISFACTION”可以有值（“失望”、“不满意”、“满意”、“非常满意”）

还有一些像这样的主数据值。

将此主数据存储在数据库中的最佳方法是什么？

为每个人制作表格似乎不是一个好的选择，因为数据是静态的（几乎不会改变）而且非常少。

另一种选择是使用检查约束。

另一种选择是在代码中创建枚举。

我正在寻找一种将这些主数据存储在数据库中的方法。我正在思考 SQL Server 2012。

任何帮助将不胜感激。

4

1 回答 1

1

来自系统分析师...

主要考虑因素是您是否要进行任何国际化。性别似乎非常简单'M'，'F'直到您认为许多语言都不是基于拉丁语的。

另一个考虑因素是数据库是否真的打算作为完全独立于应用程序的关系数据库运行（用于第三方报告、数据导入和导出等），或者数据库是否只是应用程序存储。

IMX，如果您不需要国际化，那么对于性别，我会使用andchar(1)字段。不需要除此之外的任何东西，因为对于这样的类别来说这是相当明显的（除非您的系统需要担心复杂的性别等）。同样，如果您可以摆脱或使用真/假字段并且不想使用，那很好。在整个应用程序中保持一致。不要混搭。'M''F''Y''N'bit

对于其他所有内容，我将创建一个验证表，其中包含代码、代码的描述/扩展以及（如果可能的话）一个活动列，以便用户可以指定不再使用某些代码（确保您的代码尊重这一点！）。在复杂的系统中，应用程序的系统设置区域可以允许具有 SysAdmin 访问权限的用户创建新代码，将它们标记为活动或非活动，或者在代码未使用时从验证表中删除代码。例如，他们可能希望 PROC_STATUS 为 Cancelled，或 PROC_SATISFACTION 为“无响应”。外键约束很好，但根据我的经验，许多使用这种方法的应用程序不使用 FK。

如果您的应用程序需要 i18n 并且数据需要在区域之间移植（即，德国的数据库需要能够干净地连接到中国的应用程序服务器，只需对语言更改进行一些更新），那么您就无法真正存储基表中的代码。您可能需要使用映射回验证表的整数，其中您有查找 id 整数、用户将用于其区域的代码、该代码的长名称，然后是活动/非活动选项。正确的 i18n 将包括根据安装使用正确的值预先填充这些表。

于 2014-11-06T22:16:11.520 回答