database - 将 EAV 数据从客户端转移到服务器上的关系模型

Question

我正在构建一个用于移动电子数据收集的软件平台。它应该支持任何类型的数据。例如，政府可能将其用于人口调查；一家制造公司可能会用它来评估他们工厂的工厂状况；研究机构可能会将其用于临床试验等

因此，该软件由数据库提供支持，元数据采用标准关系设计，实际数据采用实体属性值。客户端软件然后读取元数据并呈现适当的用户界面，完成规则、验证、跳过逻辑等。由于可能收集的数据的多样性，我认为选择 EAV 是一个不错的选择，但是......

一旦数据从移动客户端提交到客户的服务器，EAV 模型就不再有用，因为客户只希望他的一组(通常很少的)表用于可视化和处理。

我考虑了两种数据透视选项。

1) 数据被提交到服务器后立即进行数据透视(通过 JSON 网络服务)并将其直接保存到关系模型中。

2) 将数据保存在服务器上类似的模式中，但有一个后台进程定期对数据进行透视并将其保存在关系模型中。

第一种选择似乎更有效，因为一次旋转一条记录显然更快且 CPU 占用更少。缺点是如果元数据发生变化，这个过程需要通过相应地改变数据的关系模型来立即适应。根据更改的程度，这可能需要一些时间。更糟糕的是，如果由于任何原因失败，上传请求可能会开始被拒绝。如果使用第二种方法，这种失败不会“破坏”任何紧急情况。

是否还有其他我可能遗漏的潜在陷阱或我应该考虑的设计因素？以这种或另一种方式做事的一些充分理由是什么？我应该探索其他替代方法来解决这个问题吗？

Answer 1

只需使用 DDL 为其数据定义一个简单的表关系模式。 EAV is just an encoding of a proper schema & its metadata.当然，DBMS 无法理解，因此您几乎失去了 DBMS 的所有好处。使用 EAV 的唯一可能原因是表在编译时未知，并且 DDL 不够快或无法容纳足够的表。

EAV 请求只是 DDL 请求的文本重新排列。 (EAV 配置通常是一个用于多个实体-属性-值请求的表，给定一个表和具有虚拟表的实体的键列。)此外，只需编写一个易于实现的接口(interface)即可映射 EAV 配置-然后-更新选择的两种实现中的任何一种。 (最好使用纯关系接口(interface)并隐藏所选择的实现，但 SQL DBMS 接口(interface)的性质，即 SQL，使这变得困难。也就是说，如果使用关系 API 而不是 SQL，这将很容易。)

只有当您不在虚拟实体表上声明适当的约束或事务时，没有这种接口(interface)的 EAV 配置才会更简单。此外，每个 EAV 版本更新或查询都必须重建虚拟表，然后将这些表达式嵌入到DDL 版本的更新或查询中。 (只有在简单地插入或删除或检索单个三元组的情况下，EAV DML 才简单。)

仅如果您表明创建和删除新表是不可行的并且相应的可怕的完整性和并发性挑战的巨型连接表和元数据编码表 EAV 信息-如果你even think of using EAV，等效设计是可行的.