6

我正在考虑将个人联系人存储在业务应用程序的数据库中的最佳方式。传统且直接的方法是为每个元素创建一个包含列的表，即Name、Telephone Number、Job title、Address等......但是，这类数据有已知的行业标准，例如vCard，或hCard或vCard-RDF/XML甚至Windows Contacts XML Schema。使用标准格式会带来一些好处，例如与其他系统的互操作性。但是我如何决定使用哪种方法呢？

需求主要是存储数据。搜索和排序查询极不可能但可能。数据量最大为 100,000 条记录。

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

在第一个答案后编辑

这就是为什么我认为直截了当的方法不好的原因。这是由于这种数据的性质——它不是那么简单。

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

4 回答 4

4

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

于 2010-05-31T11:23:49.873 回答
2

看起来您没有任何实际的性能或空间问题。所以使用任何花费最少时间来编码和维护的东西！

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

于 2010-05-31T10:49:47.063 回答
1

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

user_id(foreign ey), fieldtype(string), data(string/blob)

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

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

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

于 2010-05-31T17:21:40.790 回答
0

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

于 2010-05-31T10:51:35.827 回答