具有有限可能值集的 sql id 字段的数据类型答案

【问题标题】：Data type for sql id field with limited set of possible values具有有限可能值集的 sql id 字段的数据类型
【发布时间】：2014-01-23 09:01:09
【问题描述】：

始终建议对 SQL 表中的 id 字段使用 int 类型 - 我找到了一些类似的答案 here、here 和 here。

但在所有这些问题中，id 字段是唯一的，在博客的用户表中具有许多可能的值，例如 user_id。我是否仍应将int 用于id 字段，这些字段的值范围有限，例如用户类型，可以是'admin'、'user'、'editor'？

这不是关于 users 表的问题，它仅提及例如，在我工作的真实数据库中，我经常发现此类字段具有 3-20 个可能的值，这些值很少更改，但用于许多查询、视图等，所以我们有很多SQL代码之类的。

SOME_FIELD in (1,7, 12) 
SOME_FIELD != 2

我们还可以在 UI 中显示具有此类类型的长名称的表以及该表的外键。它不是像美国公民的社会安全号码那样的自然密钥。通常在一行中有很多数据，其中包含许多字段，例如varchar(100)。我认为它会更好

SOME_FIELD in ('Draft', 'Auto-Draft' , 'Trash') 
SOME_FIELD != 'Published'

但这与我在这里找到的类似问题的所有答案直接矛盾。我尝试检查一些流行的应用程序 - Wordpress 数据库有 post_status 或 post_type 但 int for user_status 的 varchar 字段。

我还应该对这些字段使用 int 类型吗？还是个人口味的问题？

为了让问题更清楚：在其他问题的答案中提到的 varchar 键的最大问题是连接和其他操作的性能问题。这些问题是否会随着有限数量的 varchar 值而减少，在一种语言中，像 varchar(10) 和值这样的有限大小很少且仅由程序员而不是用户修改，因此来自here 或 here 或使用 IDENTITY/AUTO_INCREMENT 不相关？是否有经验丰富的开发人员对该主题的研究或实验结果？

这不仅仅是关于 MySQL 或 Wordpress 的问题，我也使用 MS SQL Server，其他 RDBMS 的数据可能会很有趣。

【问题讨论】：

我认为可能会影响设计模式的一件事是表的大小（行数）和连接时可能会受到的性能影响。非规范化很常见，但应该作为最后的手段。试想一下，如果您希望向用户呈现一个不同的 post_statusses 列表，则必须在所有帖子中选择 distinct。
如果我需要向用户显示此类数据，我通常会制作一些具有长且非常明显的名称的表格，例如“准备发送给其他组织的文档”，然后我可以为该表格创建外键。但我仍然有 SQL 代码，例如 'SOME_FIELD in (1,7, 12) 和 SOME_OTHER_FIELD != 3'

标签： sql

【解决方案1】：

如果您知道表格只会很小，那么您可以使用 smallint 和 tinyint here's 了解更多关于它们的最大值和大小的详细信息。

想要使用 int 的主要原因是使连接更容易并减小键大小（int 占用的空间比典型的 nvarchar 少得多，并且没有搭配问题）

我会提醒您 - 在 tinyint 可能已经完成的情况下使用 smallint 通常比稍后更改 PK 列的数据类型的挑战要小得多。如果有疑问，请谨慎行事！

【讨论】：