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