我需要存储用户的联系信息。我想以hCard的形式在页面上显示此数据，并以vCard的形式下载。我还希望能够通过电话号码，电子邮件等搜索数据库。

我们认为什么是存储此数据的最佳方法？由于用户可能有多个地址，所以完整的规范化将是一团糟。我正在考虑使用XML，但是我对查询XML数据库字段不熟悉。我仍然可以通过联系信息搜索用户吗？

如果这很重要，我正在使用SQL Server 2005.

解决方案

回答

我知道SQLite，但这实际上并没有帮助我说出最好的架构(无论数据库如何)来存储此数据。

回答

为什么完成规范化会"变得一团糟"？正是这种情况使规范化的混乱程度降低了。

回答

约翰(Per John)，我看不到经典标准化架构的问题所在。我们没有提供太多信息，但是我们说用户和地址之间存在一对多关系，因此我希望在地址关系中使用带有外键的沼泽标准解决方案。

回答

如果假设每个用户都有一个或者多个地址，电话号码等，则可以有一个"用户"表，一个"地址表"(包含主键，然后是对用户的唯一标识)，对于允许使用同一UserID外键的多行电话号码，这将使查询"用户X的所有地址"变得非常简单。

回答

考虑人物和他们的地址的两个表：

People (pid, prefix, firstName, lastName, suffix, DOB, ... primaryAddressTag )

AddressBook (pid, tag, address1, address2, city, stateProv, postalCode, ... )

People的主键(唯一标识每一行)为" pid"。 AddressBook的PK由pid和标记(pid，tag)组成。

一些示例数据：

人们

1, Kirk

2, Spock

地址簿

1, home, '123 Main Street', Iowa

1, work, 'USS Enterprise NCC-1701'

2, other, 'Mt. Selaya, Vulcan'

在此示例中，柯克有两个地址：一个"家"和一个"工作"。这两个中的一个可以(并且应该)在primaryAddressTag列中的" People"中被标记为外键(例如交叉引用)。

Spock有一个带有" other"标签的地址。由于那是Spock的唯一地址，因此应在pid = 2的" primaryAddressTag"列中输入值" other"。

这种模式具有很好的效果，可以防止同一个人通过意外重用标签来复制自己的地址，同时又允许所有其他人使用自己喜欢的任何地址标签。

此外，在" primaryAddressTag"中使用FK引用时，数据库系统本身将增强主地址标签的有效性(通过我们的数据库极客称之为参照完整性的事情)，因此-或者任何-应用程序不必担心它。

回答

不要担心标准化数据。像约翰提到的那样，规范化不是问题，而是解决方案。如果我们试图对数据进行非规范化只是为了避免一对夫妇加入，那么将来我们将给自己造成严重麻烦。在拥有合理大小的数据集之后，尝试重新构造此类数据将不会很有趣。

我强烈建议我们从36 Signals中查看Highrise。当我在寻找在线联系人管理器时，最近向我推荐了它。它做得非常正确。实际上，到目前为止，我对服务的唯一异议是我认为付费版本过于昂贵-仅此而已。

就目前的情况而言，我不适合固定的地址档案。我有4-5个我经常使用的电子邮件地址，5个电话号码，3个地址，几个网站和IM个人资料，所有这些我都将包含在我的联系人个人资料中。如果我们现在开始构建联系人管理系统，而不受体系结构限制的限制(请考虑将gmail cantacts键入到单个电子邮件地址)，那么请用户帮我们一个忙，并使联系人结构灵活(标准化)可能的。

干杯，-D。