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

Gar*_*art 6 database-design contacts

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

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

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

在第一个答案后编辑

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

  1. 个人联系人不是结构良好的数据,它可能被称为半结构化.每个联系人可能有不同的数据字段,甚至可能是我无法预料的字段.在我看来,这些数据的每一部分都应被视为重要信息,即因为数据库中没有相关列,所以不能丢弃任何数据.
  2. 如果我们进一步考虑,假设没有数据丢失,那么我们可以创建一个名为CommentDescriptionOther的大文本列,并将所有不能很好地拟合到表列中的内容放在那里.但话说回来 - 数据会失去结构 - 这可能是坏事.
  3. 如果我们想要结构化数据,那么 - 根据数据库设计原则 - 数据应该被分解为实体,并且应该在实体之间建立关系.但这增加了复杂性 - 实体太多了,应该制定很多设计方案,比如"我们如何存储地址?个人姓名?电话号码?我们如何编码家庭电话号码和手机号码?怎么样?联系信息?"实体之间的关系是复杂的,多个,每个关系都是数据库中的一个表.每个关系都需要在设计文件中记录.这是很多工作要做.但是可以完全避免复杂性 - 只记录根据这样的数据存储数据标准架构,期间.然后,任何阅读该文档的人都应该很容易理解它的全部内容.
  4. 最后,这完全是关于使用行业标准.希望这个标准是由一些聪明的人设计的,他们比以往任何时候都更好地预测和描述了个人联系信息的结构.我们为什么要重新发明轮子?使用标准模式要容易得多.问题是,标准太多了 - 决定使用哪一个并不容易!

Art*_*ius 2

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

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