键入要用于sql表中的“Status”列

sql database join database-design key

18229 观看

7回复

2362 作者的声誉

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

ticket
   id:int(11)PK
   名称:varchar(255)
   状态:?????????

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

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

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

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

OPEN =>“打开”

CLOS =>“已关闭”

“PEND”=>“待批准”

“PROG”=>“正在进行中

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

作者: XwipeoutX 的来源 发布者: 2011 年 8 月 26 日

回应 (7)


3

1977 作者的声誉

我建议你改为使用statusID字段,并有一个单独的表将ID映射到varchar?

编辑:我想这正是你在第3点中概述的内容。我认为这是最好的选择。

作者: Jon Martin 发布者: 26.08.2011 01:31

5

39987 作者的声誉

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

作者: James Johnson 发布者: 26.08.2011 01:32

5

5185 作者的声誉

决定

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

作者: Ian Jacobs 发布者: 26.08.2011 01:34

6

32517 作者的声誉

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

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

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

作者: Philip Kelley 发布者: 26.08.2011 02:09

3

22226 作者的声誉

我假设您的数据库具有某些描述的前端,并且常规用户不会暴露给状态代码。

因此,您的便利只适用于程序员和DBA - 重要人物,但我不会为他们优化我的设计。

更强 - 我会非常小心使用“有意义的”缩写 - 当开发人员清理一些数据并且错误地解释“有意义的”键时,我见过的最令人震惊的数据错误; 事实证明,“PROG”并不意味着“编程”,而是“正在进行中”。

选择3。

作者: Neville Kuyt 发布者: 26.08.2011 02:19

0

12335 作者的声誉

当您想要在HTML表单中显示状态列表时,创建一个具有状态的单独表是个好主意。您可以从查找表中显示详细描述,如果需求类似,它将帮助用户选择状态。

从开发的角度来看,我想将整数作为主键。如果您知道它不会超过限制,您可以使用小/小整数来优化它。

如果你使用缩写作为外键,那么你必须每次都认为它是唯一的,因为@Philip Kelley已经提到它作为它的缺点。

最后,如果您愿意,可以声明表格类型MYISAM。

更新:反映@Philip Kelley的观点,如果状态太多,那么最好使用整数作为外键。如果只有几个状态,则可以使用abbr作为外键。

作者: kta 发布者: 19.09.2015 09:39

0

31 作者的声誉

我最近一直在使用很多需要很多状态的数据库而且我有一些可能值得添加到对话中的注释。

INT:我发现的一件事是,如果一个应用程序有很多跟踪,那么参考表的数量很快就会变得难以处理,正如你所提到的那样,使数据库检查一目了然不切实际。(对于我的一些客户来说,这比处理时间节省的时间要少得多。)

VARCHAR:编程很糟糕,但重要的是要考虑一个给定的状态是否真的会被代码使用,或者仅仅是人眼。对于后者,您可以获得无限的范围,而不必保持任何关系。

CHAR(4):使用描述性char列实际上是一种非常好的方法。我通常只会考虑它的价值范围是否会很低而且显而易见,但这只是因为我认为这是一种非标准的方法(有可能混淆新的开发者)。实际上,您可以将CHAR值用作与INT相同的外键,从而获得易读性并保持性能均衡。

我不能错过的一件事就是数学运算(比如“<”和“>”)。

INT范围:我尝试过的混合策略是使用INT,但为数字添加一定程度的语义。所以,例如,

1-10 being for initial stages, 
11-20 being in progress, and 
21-30 being the final stages. 
60-69 for errors, rejections

这里的问题是,如果你发现你需要更多数字,那么你就是SOL,因为已经采用了下一个范围。所以,我最终做的是(有点)模仿HTTP响应:

100-199 being for initial stages, 
200-299 being in progress, and 
300-399 being the final stages. 
500-599 for errors, rejections

我更喜欢这个简单的INT,虽然它可以比CHAR更少描述,但它也可以不那么模糊。而“PROG”可能意味着一些东西,好的,坏的还是良性的,如果我能看到的东西是在500的范围内,我可能不知道是什么问题,我就可以告诉你,一个问题。

作者: DevBodin 发布者: 04.12.2018 05:37
32x32