2013-03-21 107 views
1

我正在为一位朋友建模贷款数据库。客户地址,物业地址和公司地址

客户可以具有0到N地址(街道地址或邮政信箱地址或甚至大于1个街道地址和比邮政信箱地址更多)。 A 物业必须只有一个地址。 A 公司(就业信息)必须只有一个地址

这将是更好的有一个单独的地址表为客户表。地址为物业公司可以属性公司表去。

但由于我们有一个地址表在这里,你认为这是一个好主意,或者不要分享地址公司属性表呢?

当我们考虑实体之间的关系,我们应切断的时间点(静态方式吗?)或者我们应该把一定范围内的时间(动态方式?)来分析它们之间的关系?例如,一家公司在某个时间点只能有一个地址,但该公司最近可能从一个地方搬到另一个地方。然后,公司可能在一定时间范围内拥有多个地址。

回答

3

因为您正在贷款,您可能想知道他们的地址在哪里,所以客户会比1到N更好。

公司(就业信息)必须只有一个地址。

然后一个公司可能有一个以上的地址在一定范围内 时间。

你有点矛盾,你为什么需要这两个地址?我认为公司只有一个官方地址,直到他们在新地址上获得所有信息,此时您可以更新数据库到新地址。

但由于我们在这里有一个地址表,你认为这是一个好主意 或不共享地址表公司和属性 表呢?

这里与建模的一些想法一个很好的链接:

http://www.databaseanswers.org/data_models/

+0

关于假设的好问题,+1。 – 2013-03-21 15:03:26

2

A公司(就业信息)必须只有一个地址。

不一定。公司可以有邮寄地址和实际地址。

由于我们在此处有一个地址表,您认为这是一个好主意还是不要共享公司和属性表的地址表?

是的,把地址放在Addresses表中是一个好主意。你的属性表将有一个地址行外键,而你的公司表将有两个外键,一个用于邮寄地址,另一个用于物理地址。邮件地址将是一个可选(空)的外键。

您需要一个CuustomerAddress表来维护Customer和Address之间的0到N关系。如果你愿意,你也可以在地址和客户之间有0到N的关系。

表看起来像这样。

CustomerAddress 
--------------- 
CustomerAddress ID 
Customer ID 
Address ID 

CustomerAddress ID是主(群集)索引。它是一个递增的整数或长整数,或其他一些唯一的ID。

您将拥有一个唯一的索引(客户ID,地址ID)。

如果要将地址与客户关联起来,您需要在地址ID,客户ID上另有一个唯一索引。

公司只能在某个时间点拥有一个地址,但该公司最近可能从一个地方搬到另一个地方。然后,公司可能在一定时间范围内拥有多个地址。

如果此信息很重要,那么您必须在CompanyAddress表中包含写入日期列。您将创建一个唯一索引(公司ID,日期降序)。这样,您从地址表中检索的第一行将是最新的地址。

+0

为什么CustomerAddress表对于0-n关系是必需的?通常一个关系表是用于n-n关系的,对吗? – 5YrsLaterDBA 2013-03-21 15:14:23

+1

这不是必需的,除非您想将地址与客户关联。 – 2013-03-21 15:38:35

1

将所有地址放在自己的表中似乎是一个非常流行的想法。开发人员喜欢寻求重复并消除它。但是在这种情况下,我会毫不犹豫地将实体状态的地址放在他们自己的专用表中,因为如果像大多数应用程序一样,不把地址视为完整的实体,则会变得过于复杂。

如果您将地址视为真实实体,那么如果两家公司以某种方式共享同一个地址,或者一个地方居住了一段时间,则另一家居住在同一地点,那么这些公司将引用相同的地址。因为当你的应用程序接受一个地址作为输入时,它会去查看是否有一个现有的地址并引用它,而不是仅仅在地址表中猛击一些垃圾。你打算做哪一个?我认为这是大满贯,这很好,因为就像大多数商业应用程序一样,如果您输入的新地址与数据库中已有的其他地址相同,您完全不关心,您无意跟踪地址作为个人的东西。这就是实体和猫粮之间的区别。

因此,通过整合,我们必须引入一个交集表并对其进行索引,并且我们所有具有地址的实体都必须加入到它中,所以我们必须考虑是要急切地获取地址还是使用延迟加载。我们把所有的地址都放在一个桶里,并且必须努力确保每个人都能够快速找到自己的地址。对于真正的实体来说,这是有道理的,因为不同的事物需要链接到同一个实体,但是我们上面建立的我们并不在乎,没有人分享这些条目。

我们通过将地址整合到一个表中来消除重复现象?无论使用相同的字段,地址最终都会在数据库中结束,我们不会节省空间。唯一的重复是在DDL中用于生成模式,我们可以通过为地址(它解决应用程序代码中的冗余)制作可重用组件(其中“组件”是Hibernate术语)并使用ORM工具来管理该模式生成模式。或者,最糟糕的情况是,忽略它,地址不会发生太大的变化,这不是你最大的问题。

您正在描述的这些需求听起来像是在为一个朋友做的项目中可疑地enterprise-y。可能你的朋友的大脑因过度暴露而被不知道他们在做什么的委员会制定的详细要求而中毒。我们不得不在工作中忍受这些垃圾,但对于个人项目呢?试着说服他。

但是,也许你的朋友正在将他的企业工作外包给你,并且你被每个客户的0-N地址卡住了。如果是这样,包含损害:专门为客户地址制作一个表格,所以您不需要交集表格,并将其他实体的地址内联。让这些只有一个地址的实体从另一个表中获取他们的地址不会为您购买任何东西,而是增加更多联接。如果您需要历史记录,请将其写入单独的历史记录表格中,以防止它出现。

+0

正如AndresL指出的,客户应该有1或N个地址。正如吉尔伯特指出的那样,一家公司可能有两个地址(街道和pobox)。您已经提出了一个非常好的观点,即一个地址可能会被多个公司共享。但如果不改变公司与地址表之间的关系,我们仍然可以满足新的要求。对?现在公司表包含两个addressId外键。使内联物业地址有意义。我可能会这样。 – 5YrsLaterDBA 2013-03-22 14:21:18

+0

@ 5YrsLaterDBA:将属性内联听起来不错。我想说的是,让项目重要的驱动数据库设计。 – 2013-03-22 14:29:12