将所有地址放在自己的表中似乎是一个非常流行的想法。开发人员喜欢寻求重复并消除它。但是在这种情况下,我会毫不犹豫地将实体状态的地址放在他们自己的专用表中,因为如果像大多数应用程序一样,不把地址视为完整的实体,则会变得过于复杂。
如果您将地址视为真实实体,那么如果两家公司以某种方式共享同一个地址,或者一个地方居住了一段时间,则另一家居住在同一地点,那么这些公司将引用相同的地址。因为当你的应用程序接受一个地址作为输入时,它会去查看是否有一个现有的地址并引用它,而不是仅仅在地址表中猛击一些垃圾。你打算做哪一个?我认为这是大满贯,这很好,因为就像大多数商业应用程序一样,如果您输入的新地址与数据库中已有的其他地址相同,您完全不关心,您无意跟踪地址作为个人的东西。这就是实体和猫粮之间的区别。
因此,通过整合,我们必须引入一个交集表并对其进行索引,并且我们所有具有地址的实体都必须加入到它中,所以我们必须考虑是要急切地获取地址还是使用延迟加载。我们把所有的地址都放在一个桶里,并且必须努力确保每个人都能够快速找到自己的地址。对于真正的实体来说,这是有道理的,因为不同的事物需要链接到同一个实体,但是我们上面建立的我们并不在乎,没有人分享这些条目。
我们通过将地址整合到一个表中来消除重复现象?无论使用相同的字段,地址最终都会在数据库中结束,我们不会节省空间。唯一的重复是在DDL中用于生成模式,我们可以通过为地址(它解决应用程序代码中的冗余)制作可重用组件(其中“组件”是Hibernate术语)并使用ORM工具来管理该模式生成模式。或者,最糟糕的情况是,忽略它,地址不会发生太大的变化,这不是你最大的问题。
您正在描述的这些需求听起来像是在为一个朋友做的项目中可疑地enterprise-y。可能你的朋友的大脑因过度暴露而被不知道他们在做什么的委员会制定的详细要求而中毒。我们不得不在工作中忍受这些垃圾,但对于个人项目呢?试着说服他。
但是,也许你的朋友正在将他的企业工作外包给你,并且你被每个客户的0-N地址卡住了。如果是这样,包含损害:专门为客户地址制作一个表格,所以您不需要交集表格,并将其他实体的地址内联。让这些只有一个地址的实体从另一个表中获取他们的地址不会为您购买任何东西,而是增加更多联接。如果您需要历史记录,请将其写入单独的历史记录表格中,以防止它出现。
关于假设的好问题,+1。 – 2013-03-21 15:03:26