我认为这是很常见的事情……您有一个数据库服务器，并且您想在其中存储客户联系信息。
您需要此人的姓名、地址、电话等。
存储地址和电话的最佳做法是什么？假设 OLTP...
多人可能有相同的电话号码（例如妻子和丈夫，或母亲和女儿）。
多人共享一个家庭。
这对于提到的特定模型来说可以正常工作，但我看不出这个模型如何在不规范化的情况下进行优化。
前任：
因此，如果我按照白皮书建议的方式设计它，personid我的address桌子和桌子上都会有一个phone。然而，由于多人可能共享同一个地址，这是不可行的。一个人可能有多个地址，甚至没有地址。所以看来我需要一个人->地址映射表以及电话映射表，否则我将对这两个表进行非规范化，并在两个人共享相同的异常情况下让一些重复电话/地址。
无论如何，我提出这个问题的目的是因为似乎很难为这类事情找到“最佳实践”，但它似乎是几乎任何类型的应用程序或数据库中都会出现的事情类型。
在一对多的关系中规范化地址和电话号码，其中一个Contact可能有许多相关Phone或Address实体非常有意义。
但是，没有必要在联系人数据库中对多对多关系中的地址和电话号码进行规范化，因为它们不是您有兴趣单独使用的实体，因为它们本身具有作为唯一实体的优点。事实上，我想说的是，在你的情况下，将它们标准化到那个水平并不是一个好的设计。
如果您正在为房地产、租赁或电话服务业务建模，即使没有人与它们相关联，您也关心房产和电话号码，那么将它们建模到这个级别可能是有意义的。在多对多设计中避免重复的地址和电话号码对某人来说比他们再次输入地址要多得多，而且避免这些重复并没有真正的好处。另外，无论如何，您最终都会得到重复（至少对于地址，除非您使用邮局例程实时清除它们），所以谁将通过并将“123 Ascot Wy #5”与“123”进行匹配Ascot Way Apt 5'? 那有什么价值呢？
正常化这个深度的通常原因不适用。假设您确实创建了一个PhoneNumber表和PersonPhoneNumber多对多关系所需的表。您有三个人使用同一个电话号码，并且他们都正确链接到该号码。现在，其中一个打电话给你，告诉你他正在改变他的电话号码。您确定要更改实际PhoneNumber记录并同时更新其他两个人的号码吗？如果他们不和他一起走怎么办？很快你就会发现你的数据被搞砸了。您也可以将名字规范化为FirstName表格，将姓氏规范化为LastName桌子！然后当“乔伊”长大并改名为“乔”时，所有其他乔伊都会自动升级。但是哎呀...“乔”已经存在，您将上面三个人之一更改为的电话号码也是...真是一团糟。
另一方面，您会PhoneID用作电话号码的代理键吗？但是电话号码实际上是少数可以作为自然键的东西之一，它们几乎甚至要求被用作自然键。然后，您的Phone表格变得毫无意义，因为它没有编码有关该电话号码的任何其他信息。它只是一个电话号码列表，这些电话号码已经存在于引用表中。不要使用这样的Phone桌子。如果你想知道两个人是否共用同一个电话号码，你只需加入或按列分组！在我看来，将电话号码与单调递增的PhoneID.
如果您阅读通用人员和组织模型，您会看到电话号码和地址实际上不是需要建模到多对多关系级别的实体——它们更像是“智能定位器”将消息路由给收件人。你到底为什么要强制三个不同的人的定位器（又名电话号码）相同？定位器有助于定位人，而不是响铃的实体电话。你不能不在乎电话或其他人可能会接听 - 你只关心一旦接听，可能会联系到感兴趣的人这一事实。
标准化。
正常化，直到它受伤。
再次正常化，直到它难以忍受。
然后调整您的查询；设计你的指数；衡量你的表现；如果此时您没有其他选择，请对最低要求进行非规范化以满足性能选项。
请记住，每一种提高一个查询性能的非规范化，本质上都会降低 tat 表集上（几乎）每个操作的性能。仅当测量实际上显示出明显的性能改进时才保留非规范化。
请记住，标准化越多，索引就越小；缓存中的索引行越多，数据库执行的速度就越快。是的，创建了很多非常小的表——它们永久保存在缓存中，因此几乎可以自由访问。