我需要一个状态列，其中包含十几个可能的值。 有什么理由我应该选择int（StatusID）而不是char（4）（StatusCode）？ 由于sql server不支持命名常量，因此在存储过程和视图中使用char作为常量时，char的描述性比int更具描述性。 为了澄清，我仍然会以任何方式使用查找表。因为我需要一个更具描述性的UI文本。因此，当我维护存储过程和视图时，这个决定只是为了帮助我作为开发人员。
现在我倾向于char（4）。特别是因为在SQL Server Management Studio中设计视图阻止我添加注释（我知道可以在脚本编辑器中添加它，但实际上我会更频繁地使用视图设计器，特别是如果视图很简单）。 StateCODE ='NEW'比StateID = 1000更易读。 我想问题是会不会出现char（4）存在问题的情况，而且由于数据库非常小，我不太关心轻微的性能损失（比如使用TinyInt和int），但更担心代码维护问题
答案 0 :(得分：3)
数据库纯粹主义者会说密钥在业务领域中没有任何意义，您应该创建一个状态表，在其中查找状态的描述和其他含义。
但对于运营商和最终用户来说，拥有描述性状态代码可能是一件幸事。它甚至不必是char（4），你可以使它变成varchar（20）。这允许他们在没有连接的情况下进行查询，并以更简单的方式检查数据库。
最后，我认为char（20）组织将更顺利地运行，并在周五早些时候回家。但int组织有更好的数据库抽象，他们可以在星期五晚上享受元编程（或在论坛上提升。）
（所有这一切都假设您正在编写业务支持软件。一个更成功的业务支持系统SAP成功使用了有意义的密钥。）
答案 1 :(得分：2)
每种方法都有许多优点和内容。我相信其他论据会支持使用char（4）。我在char上选择int的原因包括：
我总是使用查找表。它们允许保留和轻松检查值的审计跟踪。例如，如果您的某个状态代码为“MING”并且做出了商业决策，以便从特定日期将其从“MING”更改为“MONG”，则我的查找表会处理此问题。
较小的索引 - 如果您需要索引此列，它将更薄。
可扩展性 - 好吧，我说了这个词，但是如果你需要从4个字符到5个字符，例如，查找表将是一个祝福。
描述：我们在这里使用了很多TLA，一旦你知道它们是什么很好但是如果我给一个商业用户一个报告说“GDA的2007 1001”，他们不一定会认为GDA =抵达时的好死。使用查找表，我可以添加此说明。
最佳做法：无法找到指向的链接，但这可能是我在K.Tripp文章中读到的内容。目的是使您的聚类主键递增整数以优化索引。
当然，如果你绝对肯定你永远不会需要超过少数4个字符，那么就没有理由不在桌面上敲打它。
答案 2 :(得分：1)
最好的事情应该是带有定义值的查找表，然后将其与使用枚举的原始表相关联。
答案 3 :(得分：1)
整理氛围是对char 4说不的一个原因：ABcD = abCD =äBCd？
如果您有12个可能的值，为什么不使用tinyint / byte和Status表？ 如果你必须存储1000万行的状态，则3个字节不同，并且校对/字符串比较加起来。
答案 4 :(得分：1)
我遇到这个用例的地方是可以映射到我在编程时通常使用Enum的内容的列。您是否在数据库列中存储Enum的整数值或Enum的名称？老实说，我已经做到了两个方面。通常，我会问自己，数据库是否会在我正在构建的应用程序之外使用。如果是这样，我将选择人类可读的格式存储在数据库中。如果没有，那么我将选择整数值，因为它在代码中重构（它只是一个强制转换而不是解析操作）Enum时节省了一点时间。
答案 5 :(得分：0)
您还可以在int
上使用tinyint答案 6 :(得分：0)
我总是选择int，因为它们更容易映射到代码中的枚举。
答案 7 :(得分：0)
如果您正在处理大量数据和高吞吐量，那么smallint或tinyint可以在硬盘上提供更好的性能和更小的占用空间。如果您的应用程序中的数据通常直接通过Access或Cognos等应用程序查看，那么您的业务人员可能会欣赏描述性值。我知道当我分析数据作为我的数据库开发人员角色的一部分时，我厌倦了加入大量的查找表，因为我不记得1 = Foo和2 = Bar或1 = Bar和2 = Foo。 / p>
此外，虽然如果你必须通过这些代码查找可能具有较小索引的行来提高性能，但是如果你经常查找行而不得不进行连接，那么它也会受到伤害（以较小的方式）代码，但你必须包含文本值。在大多数应用程序中，这不是问题，而且可能只会在大型数据仓库/报告环境中发挥作用。