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, ... }

我应该考虑ContactMethodData在ContactContactMethod桌子上使用 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 回答