为什么在数据库中将标记/枚举存储为字符串而不是整数？

我一直在浏览一些著名CMS的SQL转储，包括Drupal 7，Wordpress（一些非常旧的版本）以及一些基于Python的自定义应用程序。

所有这些转储都包含带有字符串标志而不是整数标志的数据。例如，一个职位的状态表示为published，closed或inherit不是1，2或3。

我在数据库设计方面的经验非常有限，并且从未尝试过使用简单的SQL，但是始终有人告诉我，应该对此类数据使用数字/整数标志。显然tinyint，与例如相比，在数据库中占用的空间要少得多varchar(9)。

那我想念什么呢？这不是浪费数据存储和数据冗余吗？如果这些列使用整数而不是字符串，浏览，搜索和索引编制会不会更快一些？

是的，存储字符串而不是数字会占用更多空间。无论如何，备受赞誉的平台都这样做的原因是，他们认为该解决方案的好处大于成本。

有什么好处？您可以轻松地阅读数据库转储并了解其含义，而无需记住枚举表，即使是半官方的GUI也可能只使用值主题本身，而不转换其获得的记录。（这是磁盘空间/处理时间权衡的基本形式。）

费用呢？长期以来，数据存储容量一直不是CMS的瓶颈，因为磁盘已经变得如此大而又便宜。另一方面，程序员的时间通常会变得更昂贵-因此，从业务角度来看，将开发工作用在磁盘空间上的任何事情也是一件好事。

是的，存储诸如yes或的东西true会比tinyint占用更多的空间。这不足为奇。它还使建立索引，从而使数据库连接效率降低。对于正确的值（yesvs y），也可能造成混淆。

但是，有许多方法看起来很有效，类似于在数据库（特别是MySQL）中存储字符串。

首先，MySQL具有一种enum类型（docs），以这种方式设置时，看起来非常像布尔值或受限制的字符串集。它还强制仅输入有效值。这通常是有用得多比存储1，2或3作为值作为含义与信息传送。枚举附带的惩罚是，添加或删除类型需要更改架构。

这将我们带到一个子表和外键（适用于所有数据库）。是的，你存储一些值作为密钥（回1，2或3）和值published，closed和inherit存储在另一个表。然后使用视图（docs）可以使它看起来像表中包含字符串而不是键。这样做的好处是不需要更改架构即可从子表中添加或删除条目。

确切地讲，事物的存储方式将需要查看架构的实际DDL，以确定所使用的方法，并获得一些提示，说明它们已选择了哪些折衷方案。