我一直在为即将开展的项目进行大量的数据库设计研究。
这是经典的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)?
答案 0 :(得分：0)
经过一番思考，并考虑到客户的需求/要求，使用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_entry_values
希望这对某人有用。我也对这个设计的任何批评/反馈感兴趣。