用于在数据库中存储个人联系人的格式

Question

我正在考虑将个人联系人存储在业务应用程序的数据库中的最佳方法。传统和直接的方法是创建一个包含每个元素列的表，即名称，电话号码，职位名称，地址等...但是，有这类数据的已知行业标准，例如vCard或hCard，或vCard-RDF/XML甚至{{3 XML Schema。使用标准格式可以提供一些好处，例如与其他系统的可操作性。但是我如何决定使用哪种方法？

要求主要是存储数据。搜索和订购查询的可能性极小，但可能。数据量最多为100,000条记录。

我的数据库引擎支持原生XML列。我一直在考虑使用一些基于XML的格式来存储个人联系人。如果需要搜索和排序，则可以对此数据使用XML索引。这是一个好方法吗？您会为此推荐哪种联系人格式和架构？

在第一个答案后编辑

这就是为什么我认为直截了当的方法很糟糕。这是由于这种数据的性质 - 简单。

1. 个人联系人不是结构良好的数据，它可能被称为半结构化。每个联系人可能有不同的数据字段，甚至可能是我无法预料的字段。在我看来，这些数据的每一部分都应被视为重要信息，即因为数据库中没有相关列，所以不能丢弃任何数据。
2. 如果我们进一步考虑，假设没有数据丢失，那么我们可以创建一个名为 Comment 或 Description 或 Other <的大文本列em>并把所有不能很好地装入表格列的东西放在那里。但话说回来 - 数据会丢失结构 - 这可能会很糟糕。
3. 如果我们想要结构化数据，那么 - 根据数据库设计原则 - 数据应该被分解为实体，并且应该在实体之间建立关系。但是这增加了复杂性 - 实体太多了，应该做很多设计思路，比如“我们如何存储地址？个人姓名？电话号码？我们如何编码家庭电话号码和移动电话号码？其他联系信息怎么样？“实体之间的关系复杂多样，每个关系是数据库中的一个表。每个关系都需要在设计文件中记录。这是很多工作要做。但是可以完全避免复杂性 - 只是记录数据是根据这样的标准模式，句点存储的。然后，任何阅读该文档的人都应该很容易理解它的全部内容。
4. 最后，这就是使用行业标准。希望这个标准是由一些聪明的人设计的，他们比以往任何时候都更好地预测和描述了个人联系信息的结构。我们为什么要重新发明轮子？使用标准模式要容易得多。问题是，有太多标准 - 决定使用哪一个并不容易！

Answer 1

您提到的格式是在系统之间交换数据的好方法，但不适合在数据库中存储。不要让数据交换标准规定数据库设计。无论您使用何种数据库设计，您都可以创建一个服务或程序，以XML格式公开数据以供外部使用。

Answer 2

看起来您没有任何真正的性能或空间问题。因此，使用最少的时间来编码和维护！

您可能希望允许将数据导出为vCard / hCard等格式，但不要将它们用作应用程序的存储后端，除非您认为这会导致整体编码/维护减少。

Answer 3

我可能会为“正常”数据位（名称，地址，电话等）设置一个“正常”表结构，然后与单独的表“custom_fields”有一个＆gt;很多关系“它包含三列：

user_id（foreign ey），fieldtype（string），data（string / blob）

作为替代方案，您可以在主联系人表中添加一个blob或文本字段，其中包含自定义字段/值映射的格式化列表（您可以使用BSON，JSON或YAML来简化生活）。然后在用户打开联系人时解压缩数据。

如果您需要更快的性能并能够轻松地按自定义字段对联系人进行排序，您可能需要查看以MongoDB为单位的以文档为中心的数据库后端，甚至是适当的搜索引擎（SOLR或Google .. idk ..）可能有点矫枉过正，但也可能是一个有趣的项目！

将自定义字段和值与“普通”数据库中的条目相关联的方法有很多很多种。只需选择一个你理解的，可以快速写下来并去做。我从未见过公司/雇主关心后端数据存储系统的“标准合规性”。只要你编写某种导出脚本，或者（如上所述）编写插件来支持无缝VCARD / XML导入/导出，您可以声称您的应用符合“标准。”

Answer 4

普通数据库方法有什么问题。就像你自己提到的那样 - 有几种不同的格式，如果你实现了一种格式，那么你就会破坏与其他系统的兼容性。 使用数据库方法，您可以稍后为与外部应用程序链接所需的每种格式编写插件 - VCard或其他。