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