sql - 用于 sql 表中的 "Status"列的类型

Question

我有一个(虚拟)表结构如下:

ticket  id: int(11) PK  name: varchar(255)  status: ?????????

问题是，我应该为状态使用什么数据类型？在我看来，这是我的选择:

1. 表示状态的 varchar - BAD，因为没有完整性
2. 代表状态的枚举 - BAD 因为要更改值，我必须更改表，然后更改任何带有值下拉列表的代码，等等等等
3. int FK 到状态表 - 好是因为它是动态的，坏是因为它很难通过视觉检查(这可能很有用)
4. varchar FK 到状态表 - 很好，因为它是动态的，并且在检查时可见。 BAD，因为键是有意义的，这通常是不受欢迎的。有趣的是，在这种情况下，状态表完全有可能只有 1 列，使其成为美化的枚举

我是否准确了解了情况？拥有一把有意义的 key 真的那么糟糕吗？因为虽然它确实让我起鸡皮疙瘩，但我没有任何理由这样做......

更新:对于选项 4，建议的结构将是 status:char(4) FK，到状态表。所以，

OPEN => "打开"

CLOS => "关闭"

"PEND"=> "待授权"

"PROG"=> "进行中

在这种情况下有什么缺点？在这种情况下，我可以看到使用 int 而不是 char 的唯一好处是性能稍差。

Answer 1

我会选择数字 4，但我会使用 char(x) 列。如果您担心性能，char(4) 会占用与 int 一样多的空间(以及人们认为的磁盘 i/o、带宽和处理时间)，int 也需要 4 个字节来存储。如果您真的担心性能，请将其设为 char(2) 甚至 char(1)。

不要把它当成“有意义的数据”，把它当成自然键的缩写。是的，数据有意义，但正如您所注意到的那样，在处理数据时这可能是一件好事——这意味着您不必总是连接(即使连接到一个非常小的表)来从中提取意义数据库。当然，外键约束确保数据有效，因为它必须在查找表中。 (这也可以通过 CHECK 约束来完成，但随着时间的推移，查找表通常更易于管理和维护。)

缺点是您可能会陷入寻找意义的困境。 char(1) 具有很强的吸引力，但如果您有十个或更多的值，就很难想出好的有意义的值。 char(4) 的问题不大，但仍然是一个可能的问题。另一个缺点:如果数据可能会发生变化，那么是的，您有意义的数据(“PEND”=“待授权”)可能会失去其意义(“PEND”=“转发到总部进行初步批准”)。这是一个糟糕的例子；如果这样的代码确实发生了变化，那么重构您的系统以反射(reflect)业务规则的变化可能会好得多。我想我的观点应该是，如果它是用户输入的查找值，代理键(整数)将是你的 friend ，但如果它们是内部定义和维护的，你绝对应该考虑更人性化的值。那，或者你需要在你的显示器上做事后笔记来提醒你 Status = 31 到底是什么意思。 (我身上有三个，stickum 每隔几个月就会磨损一次。谈谈维护成本...)