数据库规范化：表设计的味道答案

【问题标题】：Database normalization: Table design smells数据库规范化：表设计的味道
【发布时间】：2011-12-20 00:10:10
【问题描述】：

我的数据库的一部分的设计方式我有三个表：

每个合作伙伴可以有零个或一个 XYZProgram。 PartnerXYZPrograms 表将合作伙伴与 XYZProgram 关联起来。所以我在 PartnerXYZPrograms 表中有以下关系/约束：

PartnerId 和 XYZProgramId 是外键； PartnerId 是唯一的，XYZProgramId 也是唯一的。

现在这似乎有味道。 6 年后我将回到 DB 设计，所以我不能立即说出这违反了哪些规范化规则，但我怀疑它正在破坏某些东西。 PartnerXYZPrograms 表很可能是多余的，XYZPrograms 表应该可能包含 PartnerId。

所以我的问题是，在设计表明数据库规范化可能搞砸的表时，气味是什么。

【问题讨论】：

【解决方案1】：

发现这些气味的最简单方法是可视化数据集在活动时的外观。与标准化相关的最明显和最基本的气味：

一个表在一个列中具有相同的冗余数据，其值不是另一个表的键（或复合键的一部分）。这应该引起警钟。如果您有一个名为 Job Listing 的实体，并且“类别”列之一包含“管理”、“管理”、“工程”、“管理”等值，这应该立即告诉您还有一个值得表示的附加概念。
- 表的列中有冗余数据，该列有时填充类似于以前的气味，有时为空。这看起来有点像上面的，但有区别。这意味着有一个单独的想法需要表示，但它是组合关系的一部分。前任。一个名为 ManagerInfoID 的员工实体，它有一个经理表中包含一些信息的记录的键。对于所有非经理，它都是空的。（我看到这个的次数超出了我的预期。
- 另一种可能的气味是看起来不正确的合并表。通常情况下，人们会默认使用链接或合并表（如 ManagerEmployee）。虽然这实际上是处理多对多关系的最佳解决方案，但有时像您上面提到的那样复杂的关系具有在合并表中似乎不正确的特征。更好的（也许？）解决方案是对零对多或一对多关系进行建模，类似于您上面提到的（通过将 PartnerId 放在 XYZPrograms 表中）。

老实说，我认为忘记规范化规则并坚持气味是一件非常好的事情。它可以防止像 #3 这样的事情发生，在这种情况下，从几年前你几乎不记得的课程中想出规则的混乱斗争通常会导致理论/实践不匹配，并且让你错误地应用原则。

关系数据库的好处是，如果没有正确建模，您看到的数据看起来真的很难看。这是由于被非规范化的数据库所困扰（或者更糟糕的是必须清理后果）。

你还能想到什么其他的气味？

【讨论】：