我正在设计一个具有不同类型地址的系统。例如，人员地址，酒店地址，机场地址，办公室地址。
我参与讨论，我认为由于地址不同（不同实体酒店，机场等），地址应存储在单独的表格中。我认为这会提高性能。
还有另一种意见是将所有地址放在同一个表中。
我正在使用PostgreSQL，我正在查看超过1000万条记录。
您认为更好的设计是什么？
我期待着你的意见。
问候，
披露：作者
我建议将地址保留在同一个表中，并使用类型字段指示它是什么类型的地址。
如果您拥有正确的索引和udpated统计数据，则1000万条记录不是难以管理的数量。
通过将它们放在同一个表中，可以确保可伸缩性。如果添加了其他类型的地址，会发生什么？对于另一个添加的表，对代码的更改会非常激烈，但如果您在现有表中只有另一种地址类型，那么它将是最小的。
由于您的地址没有不同，也就是说，它们所附加的实体具有相同的格式，我认为没有充分的理由将它们分开，至少没有任何操作数据来支持这样的决定。
无论如何，如果您发现地址存在瓶颈，请使用多个表来表示特定的实体地址，但不是之前。
就个人而言，我认为地址是一个地址，因此它们应该在同一个表中。有关它的地址类型的任何额外信息可以与链接到所有者一起存储。例如，公司可以有5个地址，CompanyAddress表可以有一个'IsHeadOffice'列以及CompanyId和AddressId等等。
对于1000万条记录，您最好将地址放入单独的表中。
此外，如果您要搜索地址，可以进一步规范化地址表。我在几个系统上工作过这样的设计：
地址表
街道表
城市表
而人，酒店，办公室等表将有一个address_id
这种问题总是很难回答，因为它真的取决于你的业务。无论如何，经典的方法是创建一个包含所有地址的表地址，并与需要拥有地址的所有实体建立关系
酒店--->地址
AirPort - >地址
等等
通过这种方式，您将能够理解实体的地址类型与其相关（或者如果您愿意，甚至可以添加地址类型表）
如果在您的业务中，您不需要将地址视为实体，但您只对其获得的值感兴趣（您通过其状态而不是通过其身份ID识别地址），您可以将地址视为值对象（不变）。在这种情况下，您可以将地址属性添加到每个“主要实体”：酒店，机场等
看看Enric Envas书和DDD概念：
http://lostechies.com/jimmybogard/2008/05/21/entities-value-objects-aggregates-and-roots/
我不认为您已经提供了有关如何使用地址以及如何检索或更新地址的足够信息。
如果它只是不同类型的地址而没有其他实体，我会将它们存储在同一个表中。
在给定适当的索引的情况下，关系数据库性能旨在通过表大小进行扩展。
确定表可能是数据库设计过程中最棘手的步骤。这是因为您希望从数据库中获得的结果（例如，您要打印的报告，您要使用的表单，您想要回答的问题）并不一定提供有关生成它们的表的结构的线索。事实上，首先在纸上绘制和重新设计您的设计可能会更好。在设计表格时，请记住以下基本设计原则来划分信息：
规范化 - 因为它是正确的逻辑设计 - 然后在必要时使用horizontal partitioning将物理设计与逻辑分开。