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