8

我一直在为即将到来的项目做大量关于数据库设计的研究。

这是典型的内部平台问题，我们的客户基本上想要无限的自定义以及在实体上创建表单和属性的能力，从最终用户那里收集它们的值，并能够在图表上显示收集到的信息。

临床医生将使用一些东西来帮助监测患者，为什么即使使用 EAV 也是一个想法，因为我们需要为不同的试运行收集不同的信息。有时这可能是他们那天吃的东西。其他可能是血糖或血压（实际上是两个数字），有时可能是多个问题（你今天从 1 到 10 的疼痛如何？），所有这些都是我们永远不会真正知道的想法提前说明最终客户将要求什么，或者真正接受的值是什么。

我们还将在整个计划中始终如一地绘制这些数据，并在不太定期的基础上生成更大的报告。

理想情况下，我希望能够尽可能多地对其进行硬编码，因为我们使用的是 SQL，并且坚持关系数据库的最佳实践将简化数据库设计和应用程序设计（我正在编写这两者）。

我们正在进行一些试运行，我的第一个倾向是从科学家那里获得尽可能多的信息，对数据库中的表进行硬编码，然后从那里构建。如果我们发现我们需要使用一个属性表和一个 attribue_value 表来收集这些属性（以及实现有趣的表单构建器，例如下拉菜单 - 因此下拉菜单选项和验证/必需），我们可以这样做稍后推出。

我基本上浏览了所有相关的堆栈溢出帖子；大多数人说避免 EAV，更好地理解应用程序的需求，并且，在某些时候，如果客户真的需要 EAV 实施，那么就去做吧。

  • 有人用过混合模型吗？你能讨论一下吗？

  • 有没有人成功实施过 EAV 模型，您能讨论一下吗？

  • 您是否有过类似的决定，决定不为看起来可能是候选人的项目实施 EAV？结果如何？

以下是我在此过程中发现的一些有趣的读物：

http://decipherinfosys.wordpress.com/2007/01/29/name-value-pair-design/ 存储时间序列数据，关系型还是非关系型？ 数据库 EAV 的优点/缺点和替代 实体-属性-值 (EAV) 的替代方案？

这个链接真的给了我很多见识。

4

1 回答 1

0

经过一番思考，并考虑到客户的需求/要求，在这里使用 EAV 模型是正确的答案。

在做了更多研究之后，我决定使用 Postrgresql 并充分利用其 HSTORE 数据类型，它允许在单个字段中存储、搜索和索引键值对。

这是一篇对 hstore 与 EAV 进行基准测试的论文： http://wiki.hsr.ch/Datenbanken/files/Benchmark_of_KVP_vs。hstore -_doc.pdf

上面的论文对 hstore 与 EAV 表进行了基准测试，hstore 遥遥领先。

我们考虑的另一个选择是拥有一个涵盖所有基础的任务表：

id、名称、value_1、value_2...note_1、notes_2

显然，这个想法让我有点死心，所以我要么使用 task_type 属性表：

一个任务由管理员给用户规定，并且有一个 task_type，task_type_attributes 用于该类型的所有任务（即，为锻炼任务定义，我们希望能够存储有关锻炼强度的信息，练习的时间等）。

用户提出任务后，他们会将 task_attributes 视为要填写的字段。他们输入这些字段，然后他们输入的 attribute_value 与患者的 task_entry 相关联（还说明他们是否完成了它，跳过了它等）

任务属性

  • ID
  • task_type_id
  • 属性
  • attribute_value_type（用于在应用程序端生成所需的字段 - 即，知道有一个下拉菜单与文本输入）
  • 最小值
  • 最大值
  • 必需的

任务入口值

  • task_entry_id
  • task_type_attribute_id
  • 价值

希望这可能对某人有用。我也会对此设计的任何和所有批评/反馈感兴趣。

于 2013-08-30T18:25:26.870 回答