我想知道我遇到的一个基本数据库设计/数据类型问题。
我有一个项目表，其中包含一个名为“experience_required”的字段。我知道这个字段总是由以下选项之一填充：实习生、初级、高级或主管。随着时间的推移，此列表可能会有所不同，但我预计其中的项目不会发生巨大变化。
我应该选择整数还是字符串？将来当我有大量这样的记录并且需要通过expeirence_required检索它们时，将它们设为整数会有所不同吗？
【问题讨论】：
标签： database database-design performance
您可能喜欢将此字段编入索引。一旦被索引的 Integer 和小的 Char String 没有太大的（读取可以忽略不计）性能差异。
【讨论】：
绝对选择整数而不是字符串。
性能会更好，你的数据库会更接近规范化。
最终，您应该创建一个名为 ExperienceLevel 的新表，其中包含字段 Id 和 Title。现有表中的 experience_required 字段应更改为另一个表上的外键。
这将是一个更强大的设计，并且在您更改可用体验级别或决定重命名体验级别的情况下会更加宽容。
你可以阅读更多关于标准化here。
【讨论】：
整数。恕我直言，字符串应该只用于存储文本数据（姓名、地址、文本等）。
此外，在这种情况下，整数更适合排序、存储空间和维护。
【讨论】：
理论上整数在索引时会占用更少的内存。 您还可以使用枚举（在 mysql 中），它看起来像字符串，但存储为整数。
【讨论】：
没关系。差异可以忽略不计。有什么区别会支持整数的选择，但这是我更喜欢短文本键的少数情况之一，因为它会在许多报告情况下将 JOIN 保存回查找表。
【讨论】：
为了让水有些混浊，我建议混合使用。从@GregSansom 的想法开始（赞成），但不是整数，而是使用CHAR(1) 数据类型，其值为 I、J、S 和 D。这将为您提供与使用 tinyint 相同的性能，并提供简单的额外优势在（如果）直接处理数据时记住助记符。稍加使用，记住“S”表示“高级”是微不足道的，而 3 没有任何内置含义 - 特别是如果，如您所建议的，随着时间的推移添加额外的值。 （例如，将试用期添加为 5，“低等级 = 低价值”的范式已经不存在了。）
这仅适用于您的项目列表非常短的情况。获取太多或太相似，很难找到可用的代码。
当然，如果这些是顺序值怎么办？当然听起来像这里。在这种情况下，不要将它们设为 1、2、3、4，而是将它们设为 10、20、30、40，以便稍后插入新的分类。这还可以让您轻松实现范围，例如“everyone
我想我的主要观点是：了解您的数据，将如何使用它，随着时间的推移它可能或将如何变化，并相应地计划和编码！
【讨论】：