sql - 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、名称、value_1、value_2... note_1、notes_2

显然，这个想法让我有点害羞，所以我要么使用 task_type 属性表:

任务由管理员指定给用户并具有 task_type，task_type_attributes 适用于该类型的所有任务(即，定义锻炼任务，我们希望能够存储有关锻炼强度的信息，练习时间等)。

一旦用户提出任务，他们就会看到 task_attributes 作为要填写的字段。他们输入这些字段，然后他们输入的 attribute_value 与患者的 task_entry 相关联(它还说明他们是否完成了它，跳过了它等)

task_attributes

id

task_type_id

属性

attribute_value_type(用于在应用程序端生成所需的字段 - 即，知道有下拉列表与文本输入)

min_value

最大值

需要

tasK_entry_values

task_entry_id

task_type_attribute_id

值(value)

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