是否应该为固定选项创建单独的表？

Question

如下所示，在数据库设计的多个位置，我都会为“选项”创建表。例如，RFP阶段。其中将包含“完成”，“出价”之类的内容。

之所以这样做，是因为有人建议我在一个已删除的问题中提出这一建议。这是执行此操作的正确方法吗？还是只有5种左右的可能性，我应该将这些选项存储为文本吗？

Answer 1

其他字段

如果诸如rfp_stage之类的可能值列表涉及的不仅仅是一个名称，那么您肯定希望在设计中添加一个查找表。例如，要跟踪用于“完成”的颜色和用于“出价”的另一种颜色，则需要在color查找表上与name一起使用第二个字段rfp_stage。

单个字段

如果每个RFP阶段的名称都是唯一的值，而没有上面讨论的颜色之类的其他项，那么您可能希望使用不带任何查找表的字符串列。

您可以在应用中强制使用可能值的列表。

作为应用执行的备份，如果您使用功能强大的数据库系统（例如Postgres），则可以define a domain设置可能的值，并要求该字段在该域中始终具有值。尝试添加或更新具有意外值的行将失败，并且数据库引擎会引发错误。

处理值更改

然后再说一次，如果任何阶段的名称都可能发生变化，例如“竞标”更改为“竞标”（含义相同，措辞不同），则查找表可以作为一个单独的表使用更新措辞的地方。无需对许多行的值进行批量更新。

国际化

同样，如果您需要本地化每个RFP阶段的显示，比如说要用法语或日语显示“完成”和“出价”，那么您需要添加查找表。您可能还会有另一个查找表来保存本地化字符串，但这不在此答案的范围内。搜索堆栈溢出，也许搜索DBA堆栈交换以获取更多信息。

枚举

最后，有些人可能使用数据库中的枚举作为替代值来表示每个可能的值。例如，“ 1”代表“完整”，“ 2”代表“出价”，依此类推。我通常会自己避免使用这种方法，因为它会使从行中读取数据变得笨拙且不方便。

上下文

与许多设计决策一样，没有明确的黄金法则。上下文很重要。