具有有限可能值集的 sql id 字段的数据类型
Posted
技术标签:
【中文标题】具有有限可能值集的 sql id 字段的数据类型【英文标题】:Data type for sql id field with limited set of possible values 【发布时间】: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' 【参考方案1】:如果您知道表格只会很小,那么您可以使用 smallint
和 tinyint
here's 了解更多关于它们的最大值和大小的详细信息。
想要使用 int 的主要原因是使连接更容易并减小键大小(int 占用的空间比典型的 nvarchar 少得多,并且没有搭配问题)
我会提醒您 - 在 tinyint 可能已经完成的情况下使用 smallint 通常比稍后更改 PK 列的数据类型的挑战要小得多。如果有疑问,请谨慎行事!
【讨论】:
以上是关于具有有限可能值集的 sql id 字段的数据类型的主要内容,如果未能解决你的问题,请参考以下文章