我正在建立一个移动电子数据收集的软件平台。它应该支持任何类型的数据。例如，政府可以用它来进行人口调查；制造公司可以用它来评估工厂的设备状况；研究机构可以用它来进行临床试验。
因此，软件由数据库提供动力，元数据和实际数据的实体属性值采用标准关系设计。然后客户端软件读取元数据并呈现适当的用户界面，包括规则、验证、跳过逻辑等。我相信选择eav是个不错的选择，因为可能会收集到各种各样的数据，但是…
一旦数据从移动客户机提交到客户的服务器，eav模型就不再有用，因为客户只期望自己的一组（通常很少）表用于可视化和处理。
我考虑了两种数据旋转的方法。
1）立即将数据提交给服务器（通过JSONWeb服务）并将其直接保存到关系模型中。
2）将数据保存在服务器上的类似架构中，但有一个后台进程定期对其进行旋转并将其保存在关系模型中。
第一种选择似乎更有效，因为一次旋转一条记录显然更快，占用的CPU更少。缺点是，如果元数据发生更改，则需要立即通过相应地更改数据的关系模型来适应此过程。根据变化的程度，这可能需要一些时间。更糟糕的是，如果由于任何原因失败，上载请求可能会开始被拒绝。如果采用第二种方法，这种失败不会“打破”任何紧迫的事情。
是否还有其他潜在的陷阱，我可能会遗漏或设计考虑，我应该作出？有什么好的理由这么做呢？为了解决这个问题，我还有其他的选择吗？
最佳答案
只需使用ddl为表的数据定义一个简单的关系模式。EAV is just an encoding of a proper schema & its metadata.当然，dbms无法理解这一点，因此实际上失去了dbms的所有好处。使用eav的唯一可能原因是编译时不知道表，ddl不够快或不能容纳足够的表。
eav请求只是ddl请求的文本重排。（eav配置通常是多个实体属性值请求的表，给定一个表和具有虚拟表的实体的键列。）此外，只需编写一个易于实现的接口来映射eav配置，然后更新到所选择的两个实现中的任何一个。（最好使用纯关系接口并隐藏所选择的实现，但是SQL数据库的接口（即SQL）的性质使这一点变得困难。如果使用的是关系api而不是sql，那就很容易了。）
只有在不对虚拟每实体表声明适当的约束或事务时，没有这样一个接口的eav配置才更简单。此外，每个eav版本更新或查询都必须重建虚拟表，然后将这些表达式嵌入ddl版本的更新或查询中。（只有在简单地插入、删除或检索单个三元组的情况下，eav dml才是简单的。）
只有当您证明创建和删除新表是不可行的，并且相应的糟糕的完整性和并发性挑战了巨型联接表和表eav信息等价设计中编码的元数据才是可行的，您才应该even think of using EAV。