关于选择数据类型

Question

如果在我的表格中的某个列中，我希望值为“是”，“否”或“可选”，那么我需要使用哪种数据类型？

Answer 1

BIT：

• 占用1个字节，但最多8个BIT字段可以合并到SQL Server中的单个BYTE中。
• 存储两个值中的一个：1（表示true）和0（表示false），因此列需要为空，以便NULL作为第三个值传递

CHAR（1）

• 需要1个字节
• 如果不区分大小写，则为26个字符，如果区分大小写，则为52，

TINYINT

• 需要1个字节
• 值为0到255

效果

所有选项都占用相同的空间，使得性能等同于JOIN /等。

比较

如果有可能改变价值，那么

BIT并不是最明智的选择。 CHAR(1)可立即读取IE：Y，N，O。TINYINT是您希望通过外键关联的表中主键的不错选择，并将描述性文本存储在另一列中。 / p>

结论：

如果不使用外键关系，

CHAR(1)将是我的选择，否则TINYINT 使用CHAR（1），具有单个字符的自然主键是不太可能的。假设一个基于主角的自然键失败，如果你有两个以相同角色开头的单词，并且如果标签需要改变则会引起悲伤，因为键也应该改变并且永久存在（除非你是懒惰的和类似的解释为什么代码不遵循与其他代码相同的方案）。 CHAR（1）还提供了TINYINT所做的大约五分之一的可能性（假设上端，52个区分大小写的值） - 人工/代理键与描述变化隔离开来。

Answer 2

使用BIT表示True / False或在您的情况下使用CHAR（1）Y / N或CHAR（3）是/否。

我真的会在这里使用CHAR（1），因为额外的2个字符不会增加任何实际值。

Answer 3

我很惊讶在这里看到如此多的“比特”投票。这是一个糟糕的选择。

从语义上讲，NULL表示“未知”，因此它不是第三个（已知）值的好选择。如果你以这种方式使用它，你可能会遇到很多问题。例如，聚合函数，GROUP BY和联接可能不会按照您期望的方式运行。用户界面可能无法将NULL作为值处理（例如，MS Access在空位字段方面存在问题）。您还无法通过定义NOT NULL字段来帮助保持数据完整性。

最后，您可能会混淆那些习惯于正常使用该值的其他数据库/应用程序开发人员。

使用CHAR或TinyInt。

Answer 4

谢尔盖和JonVD都提供了很好的解决方案，但我同意谢尔盖。可空位提供三种选择。如果它不为null，那么您知道用户已选择该选项。

Answer 5

我会使用char（1）或带有检查约束的INT。 只是为了最大限度地减少数据库与您用来访问它的任何抽象层之间的潜在不匹配。例如，JDBC没有TINYINT。

Answer 6

我同意“OMG小马”的选项，但不同意他在这种情况下的结论。

使用位列！分配一个位来保存数据可以免费提供另外六个Y / N / O和一个Y / N存储位置。当使用Bit数据类型时，始终至少将bit定义为非null，因此SQL将在数据页中为值保留一个位置。