3

哦,我写过的每一个应用程序都遇到过这个问题。我想要一个最终的共识答案!

这是在数据库中存储联系人方法或任何其他数据的最规范/有效/正确的方式吗?

Contact { PK ContactId, ... }

ContactContactMethod {PK FK ContactId, PK FK ContactMethodId, Key, Comments }

AddressContactMethod {PK FK ContactMethodId, Line1, Line2, City, State, Zip }
EmailContactMethod {PK FK ContactMethodId, EmailAddress }
InstantMessengerContactMethod {PK FK ContactMethodId, IMClient, IMAddress }
PhoneContactMethod {PK FK ContactMethodId, ... }
WebsiteContactMethod {PK FK ContactMethodId, ... }
OtherContactMethod {PK FK ContactMethodId, ... }

我应该考虑ContactMethodDataContactContactMethod桌子上使用 Xml 字段吗?

AddressContactMethod、EmailContactMethod 等都具有相同的主键唯一性,这让人感觉有些不对劲。

还考虑了联系人数据的键值对,但这比 Xml 字段更难查询。

(设计指南:每个联系人可能有一个以上的每种联系方式或没有,每个联系人都有一个非唯一的“键”,如“家、工作、红色汽车等”和评论,但类型之间没有其他共享数据元素)

4

5 回答 5

2

和你一样,我看到的不仅仅是我的联系信息数据库设计。我认为您的做法非常合理,并且将 Key 列与 *Method 表分开放置是一个不错的选择,允许按照一种方式对“家庭”电子邮件和邮政地址进行分组。

但是,我认为大多数联系人数据库都过度架构。虽然我不同意 Chris Lively 的方法,但我认为您可以通过只拥有联系信息类型(电子邮件、电话、网址等)并为每个信息存储一个简单的文本字符串来简化。尝试验证单独的类型或将它们分解为子字段通常不值得付出努力。一方面,如果您允许美国以外的联系人,所有电话和地址验证规则都会立即失效。将完整的地址存储在 Unicode 字符串中,希望最好是我的建议。

这留下了这样的设计:

Contact { PK ContactId, ... }
ContactType { PK ContactTypeId, ContactType }
ContactMethod {PK FK ContactId, PK FK ContactTypeId, PK Key, Value, Comments }

ContactMethod.Value 是文本值。

这似乎至少类似于谷歌跟踪联系人的方式。如果不出意外,他们可能已经考虑过跟踪来自地球上每个国家的无数联系人的问题。

于 2009-03-11T03:27:27.280 回答
2

这种模式有一个名称。它被称为“专业化泛化”。

在这种情况下,联系方法是联系联系人的特殊方式。

对“泛化专业化关系设计”的网络搜索将引导您找到一些以更一般的方式处理此模式的文章。对于相同模式的面向对象视图,请搜索“泛化专业化对象设计”。

于 2009-03-11T05:25:16.060 回答
1

在过去,我会使用表模式——比如:

Person [ID, Name]
ContactPoint [ID, PersonID, ContactMethod]
EmailContactPoint [ID, EmailAddress]
AddressContactPoint [ID, Line1, Line2, blah]

在不同的接触点和 ContactPoint 表之间具有 1-1 的关系 - 一种继承。ORM 之类的 Hibernate/NHibernate 和 Entity Framework 可以根据这些 1-1 关系实例化正确的类型。

现在我可能只使用 XML blob 和 SQL 中的几个函数,以便轻松处理特定类型的默认/主要联系点(例如,“GetPrimaryPhoneNumber(personID)”。

于 2009-03-11T03:22:48.710 回答
1

最终一致的答案是,每个人自己的答案都是最好的,没有人的一分钱。那就是问题所在; 没有一种方法可以满足每个人的需求。因此,可能永远不会有最终的共识答案——甚至可能没有共识答案,但几乎可以肯定不是最终答案。

于 2009-03-11T03:23:55.570 回答
0

大多数人真的过度建筑师的事情。这样看,您真正关心特定联系人的多少电话号码?通常为 1;有时 2。

地址也是如此,通常您真正需要的只是文件中的地址。

所以,考虑到这一点,看看你的应用程序。如果您真的只有 2 个电话号码,请将这些电话号码存储在 CONTACT 表中,如 HomePhone、WorkPhone 或其他。如果在未来某个时间点,您确定需要更多电话号码,请继续将这些号码拆分到单独的表格中。地址也一样。电子邮件也一样。

现实情况是,大多数 UI 不会在网格中显示电话号码。相反,它们被放置在与人名一致的位置。原因是您只需要几个数字。

总结一下:让数据库尽可能简单。UI 团队和您的数据库服务器将为此感谢您。

于 2009-03-11T03:16:28.990 回答