存储在数据库中的地址应该标准化吗?

时间:2016-04-27 13:31:34

标签: mysql sql database ms-access

快速提问。

考虑下表(英国):

  • CustomerID(PK)
  • 名字
  • House_No /名称
  • 邮编

你会将地址分成另一张桌子吗? 基本的业务假设是客户不能有多个地址。

最初我把它分开来看起来像这样:

客户表

  • CustomerID(PK)
  • 地址ID(FK)

地址表

  • AddressID(PK)
  • 邮编(FK)
  • House_Number_name

邮政编码表:

  • 邮政编码(PK)
  • StreetName
  • CityID(FK)

城市表

  • CityID(PK)
  • CITYNAME

除非我的假设错误,否则邮政编码唯一标识一个街道名称,而城市不在3NF?

4 个答案:

答案 0 :(得分:2)

就个人而言,我会将地址放在另一张表中,并将它们链接在一起。

业务假设/规则可能会发生变化,当您拆分这些内容时,您最有可能在没有重大重做的情况下适应任何可能的业务规则。

例如,oops,客户的账单地址与他们的送货地址不同,或者oops,我们需要知道去年实际发货的地方,即使客户今年更改了他们的地址等等。

答案 1 :(得分:0)

  基本的业务假设是客户不能超过   一个地址。

如果这是一个实际的规则,而不是一个假设,我只是将它们保存在一个表中。

然而,假设把“屁股”放在一边。在' u'并且'我'。

因此,请安全地将地址划分到另一张桌子中。 但看起来你的标准化程度与你的样本相差太远。

答案 2 :(得分:0)

这一切都取决于您的要求,但正如您上面提到的,客户不能有多个地址,所以不需要另一个一对一的关系,因为您可以将它放在同一个关系中。但根据我的经验,我建议你因为未来的要求而将其分解为另一对多关系。

答案 3 :(得分:0)

是的,我会将地址分成一个单独的表格。

但是,原因不是本身(在大多数情况下)。主要原因是它是一个缓慢变化的维度,查找以前的地址可能很有用。

您是否继续进行邮政编码等规范化工作是一个品味问题。在更多"业余"数据库,我认为没有必要。但是,对于真实客户的大型数据库,我倾向于将其拆分。它有助于确保邮政编码准确无误。而且,它们随着时间而变化。而且,您可能会在邮政编码级别购买其他信息。