小编Sto*_*aft的帖子

我正在设计我的第一个数据库，我发现自己对为分类变量的每个实例存储整数或字符串之间的选择感到沮丧。

我的理解是，如果我有一个包含城市的表，我想将其作为国家/地区表的子级，那么最有效的方法是将国家/地区表的 PK 作为城市表中的 FK。然而，为了便于使用和调试，最好始终将字符串名称与国家/地区 PK 相关联。我考虑过的每个解决方案要么不推荐，要么看起来过于复杂。

我想了解这些方法的优点（或了解新方法），并了解是否必须如此，或者数据库是否只是因为传统而如此。

可能的方法：

1. 使用字符串作为国家/地区的 PK。然后我将在任何子表中为其提供一个人类可读的 FK。显然，性能不如使用整数，但我怀疑这可能是获得我想要的便利的最不糟糕的方法。

2. 使用应用程序逻辑创建一个视图，将每个国家/地区的字符串名称连接到 states 表。

• 我不喜欢这个，因为如果应用程序逻辑中断，表格的可读性就会降低。另外，我预计大型连接操作的性能损失会比字符串 PK/FK 更严重。

3. 创建一个单独的表以将数字 ID 与相应的字符串 ID 连接起来。我不确定是否有一个表编码每种类型的关系会更好，或者一个大表有一个大的 ID 池来覆盖所有整数键字符串值关系。然后，我可以使用应用程序逻辑查找适当的字符串，并在用户给出字符串名称时将适当的 PK 填充到子表中。

• 我觉得这也可能是相当资源密集型的，因为每次向子级添加新行时都必须进行查找。这也意味着我仍然需要创建我想要的视图。

4. 使用enum数据类型。出于本能，这将是我的首选方法，因为它似乎是自然键和合成键之间的理想平衡：使用整数 ID 并为 ID 提供字符串标签，以便字符串本身不需要重复。

• 不幸的是，我的研究发现不建议这样做。原因之一是类别不能轻易删除。我不确定这对我来说是否是一个破坏性的因素，但我也想知道为什么 DBMS 是这样设计的。难道分类变量的常用程度不足以为它们添加便利功能吗？