这是经典的inner platform problem,我们的客户基本上需要无限的自定义,能够在实体上创建表单和属性,从最终用户收集它们的值,并能够在图表上显示收集的信息.
临床医生将用它来帮助监测患者,为什么即使使用EAV,我们也需要为不同的试运行收集不同的信息.有时可能是他们那天吃的东西.其他可能是血糖,或血压(这实际上是两个数字),其他可能是多个问题(今天你的疼痛怎么从1-10？),所有这些都是我们永远不会真正知道的提前最终客户要求的是什么,或者真正接受的是什么.
我们还将在整个计划中一致地绘制这些数据,并在较不规则的基础上生成更大的报告.
理想情况下,我希望尽可能多地硬编码,因为我们使用sql,并且坚持关系数据库最佳实践将简化数据库设计和应用程序设计(我正在编写这两者).
我们正在进行一些试运行,我的第一个倾向是从客户那里获取尽可能多的信息,对数据库中的表进行硬编码,然后从那里构建.如果我们发现我们需要使用属性表和attribue_value表来收集这些属性(以及有趣的实现表单构建器,如下拉菜单 – 从而下拉菜单选项和验证/需要),我们可以这样做后来发布.
我基本上经历了每个相关的堆栈溢出帖子;大多数人说避免EAV,更好地了解应用程序的要求,并且,在某些时候,如果客户TRULY需要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)?
解决方法
在做了一些研究后,我决定使用Postrgresql并充分利用其HSTORE数据类型,该类型允许在单个字段中存储,搜索和索引键值对.
这是一篇关于hstore与EAV的论文基准测试：
http://wiki.hsr.ch/Datenbanken/files/Benchmark_of_KVP_vs.hstore-_doc.pdf
上面的论文基准测试hstore vs一个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
> id
> task_type_id
>属性
> attribute_value_type(用于在应用程序端生成所需字段 – 即知道有一个下拉列表与文本输入)
> min_value
> max_value
>必填
tasK_entry_values
> task_entry_id
> task_type_attribute_id
>价值
希望这可能对某人有用.我也对这个设计的任何批评/反馈感兴趣.
