我的数据库的一部分设计方式我有三个表：
每个合作伙伴都可以拥有零或一个 XYZProgram。 PartnerXYZPrograms表将伙伴与XYZ程序联系起来。所以我在PartnerXYZPrograms表中有以下关系/约束：
PartnerId和XYZProgramId是外键; PartnerId是唯一的，XYZProgramId也是唯一的。
现在这似乎闻到了。我在6年后回到数据库设计，所以我不能立即说出这是什么规范化规则，但我怀疑它正在破坏某些东西。 PartnerXYZPrograms表很可能是多余的，XYZPrograms表可能包含PartnerId。
所以我的问题是在设计提示数据库规范化可能搞砸的表时，气味是什么？
答案 0 :(得分：1)
发现这些气味的最简单方法是可视化数据集在活动时的外观。与标准化有关的明显和最基本的气味：
一个表在列中具有相同的冗余数据，其值不是另一个表的键（或复合键的一部分）。这个应该引起警钟。如果您有一个名为“作业列表”的实体，其中一个“类别”列包含“管理”，“管理”，“工程”，“管理”等值，则应立即告诉您还有一个值得代表的额外概念。 / p>
表中的列中有冗余数据，有时填充类似于以前的气味，有时为空。这看起来有点像上面那个，但有一个区别。这意味着需要表达一个单独的想法，但它是组合关系的一部分。防爆。名为ManagerInfoID的Employee实体，它具有管理器表中具有一些信息的记录的键。对于所有非经理人，它都是空的。 （我经常看到这个比我想象的更多。
另一种可能的气味是合并表看起来不正确。通常情况下，人们会默认使用链接或合并表（如ManagerEmployee）。虽然这实际上是处理多对多关系的最佳解决方案，但有时像上面提到的复杂关系具有在合并表中似乎不正确的特性。更好的（可能是？）解决方案是将零到多或一对多的关系建模，类似于上面提到的（通过将PartnerId放在XYZPrograms表中）。
在我的诚实看来，我认为忘记规范化规则并坚持气味是一件非常好的事情。它可以阻止像＃3这样的事情的发生，在这种混乱的斗争中，从几年前几乎不记得的类中产生规则通常会导致理论/实践不匹配，并且你应用原则是错误的。
关系数据库的好处是，如果你的数据没有正确建模，你的数据看起来真的很难看。这是通过非规范化数据库获得一点点（或者更糟糕的是必须清理后果）。
你能想到其他什么气味？