状态字段的整数值

Question

我常常发现自己正在为数据库表创建“状态”字段。我将它们设置为TINYINT（1），因为通常我只需要一些状态值。我在代码中交叉引用这些值到数组查找，例如如下：

0 - Pending
1 - Active
2 - Denied
3 - On Hold

这一切都运行得很好，除了我现在正在尝试创建更好的数据库结构并意识到从数据库的角度来看，这些整数值实际上并不意味着什么。

现在解决这个问题的方法可能是为状态创建单独的表 - 但是数据库中可能有多个状态列，并且每个状态列都有单独的表似乎有点过分了？ （我希望每个状态都从零开始 - 所以对所有状态都有一个状态表对我来说不太理想。）

另一种选择是使用ENUM数据类型 - 但对此有不同意见。我看到很多人不建议使用ENUM字段。

那么将要走的路是什么？我是否绝对需要将这些数据放入自己的表中？

Answer 1

我认为最好的方法是为每种状态设置一个状态表。例如，order_status（“已放置”，“付费”，“处理”，“已完成”）在质量上与contact_status（“已收到”，“已回复”，“已解决”）不同，但是后者可能与供应商联系人一样适用于客户联系。

这可能已经是您正在做的事情 - 只是您的“表”是内存数组而不是数据库表。

Answer 2

我真的同意“ruakh”创建另一个结构为id statusName的表格，这很棒。但是，我想补充一点，对于这样的表格，您仍然可以将tinyint(1)用于id字段。由于tinyint接受来自0 to 127的值，这些值将涵盖您可能需要的所有状态案例。

Answer 3

您可以在不更改代码的情况下添加（或删除）状态值吗？

• 如果是，则考虑为每个状态“类型”单独查找表。您已经在代码中以通用方式处理此数据，因此您应该拥有通用数据结构。
• 我不，然后保留ENUM（或记录良好的整数）。您正在以特殊方式处理每个值，因此尝试概括数据模型的目的并不多。

---

  

（我希望每个状态从零开始 - 所以为所有状态设置一个状态表对我来说不太理想

您不应该在同一个查找表中混合使用几组不同的值（无论您的“零问题”如何）。原因：

• 单独使用简单的FOREIGN KEY将无法阻止引用错误集合中的值。
• 所有值都被强制为相同的类型，这可能并不总是可取的。

这是一种常见的反模式，它甚至有一个名称：“一个真正的查找表”。

相反，请将每个查找“类型”保留在单独的表中。这样，FK可以预测地工作，您可以根据需要调整数据类型。