我一直在为即将到来的项目进行大量的数据库设计研究。
这就是经典的inner platform problem，我们的客户基本上想要无限的自定义以及在实体上创建表单和属性，从最终用户收集它们的值并能够在图表上显示收集的信息的能力。
临床医生将使用in来帮助监视患者，为什么甚至使用EAV也被认为是我们需要针对不同的试验运行收集不同的信息。有时可能是他们那天吃的东西。其他可能是血糖或血压(实际上是两个数字)，有时可能是多个问题(今天从1到10，您的痛苦如何？)，所有这些想法都是我们永远不会真正知道的提高最终客户的确切要求，或者真正接受的值(value)是什么。
我们还将在整个程序中一致地绘制这些数据的图形，并在不定期的基础上生成较大的报告。
理想情况下，由于我们正在使用SQL，因此我希望能够尽可能多地对其进行硬编码，并且坚持使用关系数据库最佳实践将简化数据库设计和应用程序设计(我正在编写)。
我们正在进行几次试运行，我的第一个倾向是从技术人员那里获取尽可能多的信息，对数据库中的表进行硬编码，然后从那里进行构建。如果我们发现需要使用一个属性表和一个attribue_value表来收集这些属性(以及有趣的实现形式构建器，例如下拉菜单-以及下拉菜单选项和验证/必需项)，我们可以这样做以后发射。
我基本上已经遍历了每个relevent堆栈溢出的帖子；多数人说避免使用EAV，可以更好地了解应用程序的要求，并且在某个时候，如果客户TRULY需要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.
最佳答案
经过一番思考，并考虑到客户的需求/要求，在这里使用EAV模型是正确的答案。
经过更多研究后，我决定使用Postrgresql并充分利用其HSTORE数据类型，该数据类型允许在单个字段中存储，搜索和索引键值对。
这是一个基准测试hstore vs 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
tasK_entry_values
希望这对某人有用。我也会对此设计的所有批评/反馈感兴趣。
关于sql - EAV模型的替代方案vs混合策略vs简化和改进构建，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/18490392/