我正在考虑在业务应用程序的数据库中存储个人联系人的最佳方法。传统且直接的方法是创建一个表格，其中包含每个元素的列，即姓名、电话号码、职位、地址等...但是，此类数据有已知的行业标准，例如 vCard ，或hCard ，或vCard-RDF/XML甚至Windows Contacts XML 架构。使用标准格式会带来一些好处，例如与其他系统的互操作性。但我如何决定使用哪种方法呢？
需求主要是存储数据。搜索和排序查询的可能性极小，但也是可能的。数据量最大为100,000条记录。
我的数据库引擎支持 native XML 列。我一直在考虑使用一些基于 XML 的格式来存储个人联系人。然后，如果需要搜索和排序，就可以在该数据上使用 XML 索引。这是一个好方法吗？您会为此推荐哪种联系人格式和架构？
在第一个答案后进行编辑
这就是为什么我认为直接的方法不好。这是由于此类数据的性质 - 它并不那么简单。
- 个人联系人不是良好结构化的数据，可以称为半结构化。每个联系人可能有不同的数据字段，甚至可能是我无法预料的字段。在我看来，每一条数据都应该被视为重要信息，即任何一条数据都不能因为数据库中没有相关列而被丢弃。
- 如果我们更进一步，假设不会丢失任何数据，那么我们可以创建一个名为 Comment 或 Description 或 Other 的大文本列em> 并将所有不能很好地适应表格列的内容放在那里。但话又说回来 - 数据会丢失结构 - 这可能很糟糕。
- 如果我们想要结构化数据，那么根据数据库设计原则，数据应该分解为实体，并且应该在实体之间建立关系。但这增加了复杂性 - 实体太多了，应该做出很多设计决策，例如“我们如何存储地址？个人姓名？电话号码？我们如何对家庭电话号码进行编码？”手机号码？其他联系信息呢？……”实体之间的关系复杂且多样，每个关系都是数据库中的一张表。每个关系都需要记录在设计文件中。这需要做很多工作。但完全避免复杂性是可能的——只需记录数据是根据这样那样的标准模式存储的。那么任何阅读该文档的人都应该很容易理解它的全部内容。
- 最后，这一切都与使用行业标准有关。希望该标准是由一些聪明的人设计的，他们比我更好地预测和描述了个人联系人信息的结构。为什么我们都要重新发明轮子？使用标准模式要容易得多。问题是，标准太多了 - 决定使用哪一个并不容易!
最佳答案
您提到的格式是在系统之间交换数据的好方法，但不适合在数据库中存储。不要让数据交换标准决定数据库设计。无论您使用什么数据库设计，您始终可以创建一个服务或程序，以 XML 格式公开数据以供外部使用。
关于database-design - 在数据库中存储个人联系人的格式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2942927/