用于存储血型的 MySQL 数据类型？答案

【问题标题】：MySQL Datatype for storing bloodtype?用于存储血型的 MySQL 数据类型？
【发布时间】：2016-10-27 14:07:51
【问题描述】：

哪种 MySQL 数据类型更适合存储血型（所需的数据量最少）？换句话说，存储一到两个带有“+”或“-”符号的字母。

谢谢

【问题讨论】：

你喜欢什么
我的第一个想法是一个 ENUM，带有可能的值。（A+、A-、B+、B-、AB+ 等...）使用 ENUM 有一些 caveats。此外，由于它的数据量很小，因此 VARCHAR(3) 也应该可以正常工作。
我投票给ENUM 这个用例。

【解决方案1】：

这在很大程度上取决于您的需求。就个人而言，我可能会为每种类型分配一个数值并使用tinyint。但是，如果您希望行更直接可读，CHAR(3) 或 VARCHAR(3) 可能更合适。事实上，这是我什至建议使用ENUM 的少数几种情况之一（因为您不太可能需要在可能的值中添加或删除）。

【讨论】：

我会提醒在大多数情况下不要使用枚举；实际上，根据我的经验，以后不需要扩展有效值列表是很少见的，并且要求对多年数据进行更改表可能会很痛苦。这一点以及对各种数据库访问库中枚举类型的支持可能有点欠缺。
@Uueerdo -- 这种谨慎已经过时了。几个版本之前，ALTERing 和 ENUM 变得非常高效 -- if 您只是在 end 上添加新值。
@RickJames 考虑到现代硬盘驱动器的大小和成本，甚至后来的固态硬盘，这几乎不是问题。它只有 3 个字符，其中 2 个是保证使用的。剩下的第 3 个（假设数据分布与自然相对应）将仅使用 4% 的时间；但 varchar 也将使用一个字节来指定长度。计算完成后，varchar 将每行节省 2.84 个字节；或每约 360000 行花费一个 MB。枚举会节省更多，但不值得它有时表现出的相对古怪的行为，以及需要处理的 db API 中的参差不齐的支持。
如果空间（或速度）如此重要，tinyint 将是最佳选择。它甚至可以从表示 A[yes|no]|B[yes|no]|positive[yes|no] 的 3 位值编码，其中 0 为负数。
CHAR(3) 会为 utf8 占用更多空间——总是 9 个字节； VARCHAR(3) 不会，它会是 3-4 个字节，不管 CHARACTER SET（假设血型只使用英文字符）。