键入要用于sql表中的"Status"列

Question

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

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

问题是,我应该将哪种数据类型用于状态？我看到以下是我的选择:

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

我是否准确了解了情况？有一个有意义的钥匙真的那么糟糕吗？因为虽然它确实给了我鸡皮疙瘩,但我没有任何理由这样做......

更新: 对于选项4,建议的结构将状态:char(4)FK,状态表.所以,

OPEN =>"打开"

CLOS =>"已关闭"

"PEND"=>"待批准"

"PROG"=>"正在进行中

在这种情况下有什么缺点？在这种情况下,我可以看到使用int over char的唯一好处是轻微的性能.

Answer 1

我会选择4号,但我会使用char(x)专栏.如果你担心性能,char(4)会占用尽可能多的空间(或者人们会想到,磁盘i/o,带宽和处理时间)作为int,这也需要4个字节来存储.如果你真的担心性能,那就把它变成char(2)甚至是char(1).

不要将其视为"有意义的数据",将其视为自然键的缩写.是的,数据有意义,但正如您已经注意到在处理数据时这是一件好事 - 这意味着您并不总是必须加入(即使是一个简单的小表)来从中提取意义数据库.当然,外键约束可确保数据有效,因为它必须位于查找表中.(这也可以通过CHECK约束来完成,但查找表通常更容易管理和维护.)

缺点是你可能会陷入尝试找到意义.CHAR(1)具有很强的吸引力,但如果你到十个或更多的价值,它可以变得很难拿出好的有意义的值.char(4)不是问题,但仍然是一个可能的问题.另一个缺点:如果数据可能会发生变化,那么是的,您有意义的数据("PEND"="待批准")可能会失去意义("PEND"="转发到主页以获得初始批准").那是一个糟糕的例子; 如果这样的代码确实发生了变化,那么重构系统以反映业务规则的变化可能要好得多.我想我的观点应该是,如果它是用户输入的查找值,代理键(整数)将是你的朋友,但如果它们在内部定义和维护,你肯定应该考虑更人性化的值.那,或者你需要在你的显示器上提供post-em音符,以提醒你状态= 31应该是什么意思.(我有三个,每隔几个月就会磨损一次.谈论维持费用......)

Answer 2

我将使用INT,并创建状态表的外键关系.对于枚举状态列,INT绝对应该是安全的.

Answer 3

使用数字3.如果您想要检查某些内容,请创建一个加入状态值的视图.