规范化或不规范化

Question

我正在设计一个具有不同类型地址的系统。例如，人员地址，酒店地址，机场地址，办公室地址。

我参与讨论，我认为由于地址不同（不同实体酒店，机场等），地址应存储在单独的表格中。我认为这会提高性能。

还有另一种意见是将所有地址放在同一张表中。

我正在使用PostgreSQL，我正在查看超过1000万条记录。

您认为更好的设计是什么？

我期待你的意见。

此致

Shardul

Answer 1

我建议将地址保留在同一个表中，并使用类型字段指示它是什么类型的地址。

如果你有正确的索引和udpated统计数据，1000万条记录不是难以管理的数量。

通过将它们放在同一个表中，可以确保可伸缩性。如果添加另一个类型的地址会怎样？对于另一个添加的表，对代码的更改会非常激烈，但如果您在现有表中只有另一种地址类型，那么它将是最小的。

Answer 2

由于您的地址没有不同，也就是说，它们所附加的实体的格式相同，我认为没有充分的理由将它们分开，至少没有任何运营数据来支持这样的决定。

无论如何，如果您发现地址存在瓶颈，请为特定实体地址使用多个表，但之前不要使用。

Answer 3

就个人而言，我认为地址是一个地址，因此它们应该在同一个表中。有关它的地址类型的任何额外信息可以与链接到所有者一起存储。例如，公司可以有5个地址，CompanyAddress表可以包含“IsHeadOffice”列以及CompanyId和AddressId等等。

Answer 4

对于1000万条记录，您最好将地址放入单独的表中。

此外，如果您要搜索地址，可以进一步规范化地址表。我在几个系统上工作过这样的设计：

地址表

• ADDRESS_ID
• city_id - 这是多余的，但加快了搜索速度
• street_id
• street_number（varchar，可能是“32 / c 2nd floor 15”）

街头表

• street_id
• city_id
• STREET_NAME

城市表

• city_id
• CITY_NAME

人员，酒店，办公室等表格将有address_id

Answer 5

总是很难回答这类问题，因为它真的取决于您的业务。 无论如何，经典的方法是创建一个包含所有地址的表地址，并与需要拥有地址的所有实体建立关系

酒店---＆gt;地址

AirPort - ＆gt;地址

等

通过这种方式，您将能够理解实体与地址类型相关的信息（或者如果您愿意，甚至可以添加地址类型表）

如果在您的企业中您不需要将地址视为实体，但您只对其获得的价值感兴趣（您通过其状态而不是通过其身份ID识别地址），您可以将地址视为值对象（不可变）。在这种情况下，您可以将地址属性添加到每个“主要实体”：酒店，机场等

看看Enric Envas书和DDD概念：

http://lostechies.com/jimmybogard/2008/05/21/entities-value-objects-aggregates-and-roots/

Answer 6

我认为您没有提供足够的信息来说明地址的使用方式以及如何检索或更新地址。

如果它只是不同类型的地址而没有其他实体，我会将它们存储在同一个表中。

关系数据库性能旨在通过适当的索引可扩展为表大小。

Answer 7

确定表可能是数据库设计过程中最棘手的一步。这是因为您希望从数据库中获得的结果（例如，您要打印的报告，您要使用的表单，您想要回答的问题）并不一定提供有关生成它们的表的结构的线索。事实上，首先在纸上绘制和重新设计您的设计可能会更好。在设计表格时，请记住以下基本设计原则来划分信息：

• 表格不应包含重复信息和信息 表格之间不应重复（例如，存储每个客户 地址和电话号码一次，在一个表格中。

• 当每条信息只存储在一张表中时，您就是 在一个地方更新它。这更有效，也消除了 包含不同的重复条目的可能性 信息。

• 每个表应包含有关一个主题的信息。每个时候 表中只包含一个主题的事实，您可以维护 关于每个主题的信息独立于其他主题 （例如，您将客户地址存储在另一个表中 客户的订单，以便您可以删除一个订单 维护客户信息。）

Answer 8

规范化 - 因为它是正确的逻辑设计 - 然后在必要时使用horizontal partitioning将物理设计与逻辑分开。