我一直在为即将开始的项目进行数据库设计的大量研究。
这是经典的内部平台问题，我们的客户基本上希望无限定制并能够创建实体上的表单和属性，收集来自最终用户的值，并能够将所收集的信息显示在图表上。
它将成为临床医生监测患者的工具，使用EAV的原因是我们需要为不同的试验运行收集不同的信息。有时可能是他们当天吃了什么。其他时候可能是血糖或血压（这实际上是两个数字），而另一些时候可能是多个问题（您今天从1-10的疼痛情况如何？），所有这些都是根据我们永远无法预先知道客户最终会询问什么或接受什么值的想法。
我们还将始终在程序中一致地绘制这些数据，并定期生成更大的报告。
理想情况下，我希望尽可能硬编码所有这些内容，因为我们正在使用SQL，并坚持关系数据库最佳实践将简化数据库设计和应用程序设计（我都在编写）。
我们正在进行几个试运行，我的第一个想法是尽可能从客户那里获取尽可能多的信息，硬编码数据库中的表，然后从那里开始构建。如果我们发现我们需要使用属性表和属性值表来收集这些属性（以及有趣的实现表单构建器的事情，如下拉菜单-因此下拉菜单选项和验证/必填项），则可以在稍后的版本中这么做。
我已经阅读了基本上每一篇相关的堆栈溢出文章; 大多数人都说要避免EAV，更好地了解应用程序的需求，并且，在某些时候，如果客户确实需要EAV实现，那么就去做吧。
是否有人使用过混合模型？能谈谈它吗？
是否有人成功实施了EAV模型，能谈谈它吗？
你是否曾经遇到类似的决策，决定不为看起来可能是候选者的项目实施EAV？结果如何？
以下是我找到的一些有趣阅读资料：
Here are the translations:Name-Value Pair Design 存储时间序列数据，关系型还是非关系型？ 数据库EAV的优缺点及替代方案 除了EAV之外的实体属性值（Entity-Attribute-Value）的替代方案？
多个固定表格与灵活的抽象表格相比较 - 这个链接给了我很多启发。