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