我一直在为即将到来的项目做大量的数据库设计研究。
这是一个经典的内部平台问题，我们的客户基本上想要无限的定制，并能够在实体上创建表单和属性，从最终用户那里收集值，并能够将收集到的信息显示在图形上。
In将被临床医生用来帮助监测患者，为什么即使使用EAV也是一种想法，因为我们需要为不同的试验收集不同的信息。有时可能是他们那天吃的东西。其他时候可能是血糖或血压（实际上是两个数字），还有一些时候可能是多个问题（从1-10开始你今天的疼痛程度如何
我们还将在整个程序中一致地绘制这些数据，并在不太定期的基础上生成更大的报告。
理想情况下，我希望能够像使用SQL一样，尽可能多地硬编码这些内容，并且坚持关系数据库的最佳实践将简化数据库设计和应用程序设计（我正在编写这两个部分）。
我们正在进行一些试运行，我的第一个倾向是从ciets中获得尽可能多的信息，对数据库中的表进行硬编码，然后从那里构建。如果我们发现我们需要使用一个属性表和一个attribue_value表来收集这些属性（以及实现表单构建器的乐趣，如下拉菜单选项和验证/必需），我们可以在以后的启动中这样做。
我基本上浏览了所有相关的堆栈溢出帖子；大多数人说，避免EAV，更好地了解应用程序的需求，在某个时候，如果客户确实需要EAV实现，那么就去做吧。
-
有人使用过混合动力车型吗？你能讨论一下吗？
-
有人成功地实现过EAV模型吗？你能讨论一下吗？
-
你是否也做出过类似的决定，决定不为一个看起来可能是候选人的项目实施EAV？结果如何？
以下是我一路上发现的一些有趣的读物：
http://decipherinfosys.wordpress.com/2007/01/29/name-value-pair-design/存储时间序列数据，关系数据还是非关系数据？数据库EAV优点/缺点和备选方案实体属性值（EAV）的替代方案？
这个链接真的给了我很多见解。
经过一些思考，并考虑到客户端的需求/请求，使用EAV模型是正确的答案。
在做了更多的研究后，我决定使用Postrgresql并充分利用其HSTORE数据类型，它允许在单个字段中存储、搜索和索引键值对。
以下是一篇关于hstore与EAV的基准测试论文：http://wiki.hsr.ch/Datenbanken/files/Benchmark_of_KVP_vs.hs存储-doc.pdf
上面的论文将hstore与EAV表进行了比较，hstore遥遥领先。
我们考虑的另一个选择是建立一个涵盖所有基础的任务表：
id，name，value_1，value_2…note_1，notes_2
显然，一想到这一点，我就有点崩溃了，所以我要么使用task_type属性表：
任务由管理员指定给用户，并具有task_type，tasktypeattributes用于该类型的所有任务（即，定义对于锻炼任务，我们希望能够存储有关锻炼强度、锻炼时间等的信息）。
一旦用户提出任务，他们就会将task_attributes视为要填写的字段。他们输入这些字段，然后他们输入的attribute_value与患者的task_entry相关联（还说明他们是否完成了任务、跳过了任务等）
任务属性
- id
- task_type_id
- 属性
- attribute_value_type（用于在应用程序端生成所需的字段，即知道有下拉列表和文本输入）
- 最小值
- 最大值
- 必需
tasK_entry_values
- task_entry_id
- task_type_attribute_id
- 价值
希望这对某人有用。我也会对这个设计的任何和所有的批评/反馈感兴趣