我希望这不会是一个愚蠢的问题。我对数据库规范化的概念有些困惑，这似乎表明在特定字段/列中有任何类型的可预测或重复数据时，最好创建一个新表并通过外部 ID 链接，这真的是每种情况都需要？
例如，Gender、Business Type 等字段（没有严格的功能用途，只有信息） , Salutation（先生、夫人等），所有这些都会在整个表格中重复出现，这似乎有点过头了，让我不得不创建一个新表格对于这些？它还使我在检索数据时必须使用更多的 JOIN。
什么时候有必要对重复数据使用单独的表，或者最好的做法是对所有内容都这样做？
【问题讨论】：
标签： mysql sql database database-normalization
我对数据库规范化的概念有点困惑，它 似乎暗示有任何可预测的或 在特定字段/列中重复数据，那么最好创建一个 新表和外国ID链接，这对每个人来说真的有必要吗 情况？
你读错书了。规范化有时涉及将属性从一个关系移动到另一个关系；规范化从不涉及用 ID 号代替文本。
当您需要对允许用户放入列中的值进行某种控制时，您可以使用附加表。
要限制允许用户在列中输入的值，例如“业务类型”，您可以添加一个包含所有已知有效值的表，然后为其设置外键引用。
您还可以使用 CHECK 约束来限制值，但是当您发现新的有效值时，您必须更改架构。如果使用表和外键约束，则只需在表中插入一行。在您的情况下， CHECK 约束将适用于“性别”；表格可能更适合“业务类型”和“称呼”。
【讨论】：
一般来说，当您关心正确的数据输入时，我建议您使用 ENUM。例如，如果你想找到所有性别为 MALE 的人，如果你能保证性别字段中总是有一个大写的 M，而不是小写的 m，或者一个代表“guy”的 G，那就太好了，因为前面-end 应用程序包含错误。
如果您关心正确的数据输入并且有与该概念相关的其他信息，我建议您将其分解到单独的表格中。例如，如果“业务类型”与 TAX_RATE 相关联，您可能想要创建一个 business_types 表。
如果您信任您的前端应用程序，并且您没有与字段关联的真正业务逻辑 - 并且数据没有固有的业务限制，例如在问候语中，只需有一个 varchar 字段，前端可以在其中转储其数据。
【讨论】：
将任何单个属性删除到另一个表并用另一个表示相同事物的单个属性替换它与规范化无关。出于其他原因做这样的事情可能有用也可能没用，但这不是规范化。
【讨论】：
你只需要使用常识。 除非遗传学提出新的东西，否则您可以安全地在 Gender 字段中使用 M/F 值（当然要注意本地化）。 对于这些往往是动态的列表，您需要单独的表格 - 因此可以从一个地方获得所有可能的选项。
【讨论】：
对于像性别这样的事情，我想说一个简单的 CHAR 字段就足够了。即“M”、“F”、“U”（未知）。但是对于业务类型，我建议将其分解为单独的表格。一方面，业务类型可能会相当长，您可能需要在任何给定时间添加更多，并且您可能希望更改业务类型。
【讨论】：
规范化的重点是确保关于一个实体的相同信息不会被存储两次（因为它可能而且很可能会变得不一致）。显然，同一张表中的不同实体将具有相同的字段，当然其中许多将是 F 和许多 M。这不是问题。您唯一不应该做的事情是存储冗余数据每条记录，例如 GENDER:f,TERM_OF_ADDRESS:Ms - 最好通过查找表来完成。
此外，您不需要仅仅因为架构中的不同表具有相似的字段（例如 TYPE 或 GENDER）而进行规范化。只要确保那些真的是独立的表！例如，如果您在表 EMPLOYEE 中描述员工，并且该表包含性别信息，那么即使性别可能与医学相关，也可能不应该将其存储在链接的 HEALTH_RECORD 表中。
【讨论】：
如果您想要一个完全规范化的数据库设计，那么，是的，您应该将所有重复实体放在单独的表中。
对于像 gender 这样的字段，它会带来包含男性/女性等描述性信息的好处，而不是像 M/F 或 True/False 这样的代码。
另一方面，正如您所说，每个新表都使获取数据变得更加复杂，因此在实践中您尝试找到一个相当好的标准化平衡。
【讨论】：
您可以将 ENUM(Mr, Mrs) 或 ENUM(Male,Female) 用于此类数据。
【讨论】：