首先，我不是 DBA，我是一名软件工程师，并且一直在构建应用程序，这些应用程序在我的整个职业生涯中都是由数据库支持的。我记得的一件事（可能是错误的）是，在设计 ERD 时，您要考虑现实世界，因为它是您设计的背景。
我有一种情况，我们有一个客户的概念，他可以有两个而且只有两个电话号码。一个客户也可以有零到多个地址，并且每个地址只能有两个电话号码（以及一个指示该号码是否为手机号码的标志）。地址上的号码仅用于联系该特定地址的某人，而客户的号码则用于联系客户（其地址可能不在系统中）。
我想出的设计是将 Phone1 Phone2 作为列在客户表和地址表上。我有其他人建议这不是一个好的设计，我应该创建一个 PhoneNumber 表（我不确定他们是如何建议我将这些号码与其他记录相关联的）。
当然，我也可以看到它是有效的，但我仍然需要在客户和地址表中包含 Phone1Id 和 Phone2Id，或者在 Phone 表中有一些东西告诉我哪个记录拥有该号码。我遇到的问题当然是使应用程序逻辑更加复杂，因为我现在需要添加、删除或更新电话表中的记录，而不仅仅是将相应表中的值清空或归零。
我的设计也可以接受吗？一个还是另一个更可取？或者两者都一样有效？
反空旅会坚持让您进一步规范化以创建建议的 PhoneNumber 表。实用的人会认为您的原始设计完全可以接受。我在后者阵营。
除了 Mark Storey-Smith 和 Damir Sudarevic 的合理论证之外，我还要补充两点我认为需要牢记的要点。
我从不说永远（几乎永远）
我关于永不的政策是，如果它是想象出来的，那么它在某个时候是不可避免的。当用户告诉您某事永远不会发生时，请不要相信。就您的目的而言，这意味着您需要考虑围绕电话号码更改设计的可能性和严重性。所有的设计都是为了做出明智的妥协。做有意义的事情，考虑到需求改变时所涉及的风险。
规范化至关重要 - 除非它不是
除非您有充分的理由不这样做，否则您的第一直觉应该始终是规范化您的架构。这是因为规范化是一个很好的经验法则，可以防止您为自己创建大数据一致性和代码维护问题。
有理由去规范化。一大问题是在读取静态数据时报告性能。您可能考虑进行非规范化的另一个原因是所讨论的数据对您的系统没有意义。我是什么意思？需要由您的系统解释的数据是有意义的。正在运行但未被您的软件读取、处理或解释的数据并不是特别有意义。在一致性方面，没有意义的数据的风险要小得多。
就您的情况而言，出于实际目的，如果您的系统将电话号码用于 IVR 系统，这将非常有意义。另一方面，如果电话号码唯一的用途是让用户在蓝月亮中从屏幕上读取一次，那么也许您可以承担一点“草率”。