sql - 您应该为固定选项创建单独的表吗？

Question

如下所示，在我的数据库设计中的多个位置，如果您愿意，我正在为“选项”创建表。例如，RFP 阶段。其中包含“完成”、“投标”等内容。

我这样做是因为在一个已删除的问题中曾有人向我推荐过它。这是正确的方法吗？还是我应该将这些选项存储为文本，因为只有 5 种左右的可能性？

Answer 1

附加字段

如果您的可能值列表(如 rfp_stage)涉及的不仅仅是一个名称，那么您肯定希望在您的设计中添加一个查找表。例如，要跟踪用于“Complete”的颜色和用于“Bidding”的另一种颜色，那么您需要第二个字段 color 以及 rfp_stage 上的 name 查找表。

单个字段

如果每个 RFP 阶段的名称是唯一的值，没有像上面讨论的颜色这样的附加项，那么您可能希望使用没有任何查找表的字符串列。

您可以在您的应用中强制执行一系列可能的值。

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

处理值的变化

再说一次，如果任何阶段的名称都有可能发生变化，例如“Bidding”变为“Out for bid”(含义相同，措辞不同)，那么查找表就可以用作单一的更新措辞的地方。无需对多行值执行大量更新。

国际化

同样的，如果你需要本地化每个RFP阶段的显示，比如用法语或日语显示“Complete”和“Bidding”，那么你需要添加查找表。您可能还有另一个查找表来保存本地化字符串，但这超出了本答案的范围。搜索 Stack Overflow 和 DBA Stack Exchange 以获取更多信息。

枚举

最后，有些人可能会使用数据库中的枚举作为替代值来表示每个可能的值。例如，“1”代表“完成”，“2”代表“投标”，等等。我自己通常会避免使用这种方法，因为它会使从行中读取数据变得尴尬和不方便。

上下文

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