EAV 模型的替代方案 vs 混合策略 vs 简化和改进构建

Question

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

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

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

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

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

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

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

• 有人用过混合模型吗？可以讨论一下吗？

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

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

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

http://decipherinfosys.wordpress.com/2007/01/29/name-value-pair-design/ Storing time-series data, relational or non? Database EAV Pros/Cons and Alternatives Alternatives to Entity-Attribute-Value (EAV)?

And the link that really gave me a ton of insight.

Answer 1

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

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

这是一篇对比 hstore 与 EAV 的论文： http://wiki.hsr.ch/Datenbanken/files/Benchmark_of_KVP_vs.hstore-_doc.pdf

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

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

id、name、value_1、value_2...note_1、notes_2

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

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

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

task_attributes

• 身份证
• task_type_id
• 属性
• attribute_value_type（用于在应用端生成所需的字段 - 即，知道有下拉菜单还是文本输入）
• min_value
• 最大值
• 需要

task_entry_values

• task_entry_id
• task_type_attribute_id
• 价值

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