Pivotando dados EAV do cliente para um Modelo Relacional no servidor

Estou construindo uma plataforma de software para coleta de dados eletrônicos móveis. Deve suportar qualquer tipo de dados. Por exemplo, o governo pode usá-lo para uma pesquisa populacional; uma empresa de manufatura pode usá-lo para avaliar a condição da planta em suas fábricas; uma organização de pesquisa pode usá-lo para ensaios clínicos, e.t.c

Como tal, o software é alimentado por um banco de dados, com design relacional padrão para os metadados e valor de atributo da entidade para os dados reais. O software cliente lê os metadados e renderiza a interface do usuário apropriada, completa com regras, validações, ignorar lógica e assim por diante. Acredito que a escolha do EAV seja boa devido à diversidade de dados que podem ser coletados, mas ...

Depois que os dados são enviados dos clientes móveis para o servidor do cliente, o modelo EAV não é mais útil porque o cliente espera apenas seu conjunto de (geralmente muito poucas) tabelas, para visualização e processamento.

Eu considerei duas opções para girar os dados.

1) Gire os dados imediatamente após serem enviados ao servidor (por meio de um serviço da Web JSON) e salve-os imediatamente em um modelo relacional.

2) Salve os dados em um esquema semelhante no servidor, mas tenha um processo em segundo plano que os gira periodicamente e os salva em um modelo relacional.

A primeira alternativa parece mais eficiente, pois girar um registro de cada vez é obviamente mais rápido e menos intensivo da CPU. A desvantagem é que, se os metadados forem alterados, esse processo precisará se adaptar imediatamente, alterando o modelo relacional para os dados de acordo. Dependendo da extensão das alterações, isso pode levar algum tempo. Pior, se falhar por algum motivo, as solicitações de upload podem começar a ser recusadas. Se usar a segunda abordagem, essa falha não "quebraria" nada tão urgente.

Existem outras armadilhas em potencial que podem estar faltando ou considerações de design que devo fazer? Quais são algumas boas razões para fazê-lo de uma maneira ou de outra? Existem outras alternativas que devo explorar para resolver esse problema?

questionAnswers(1)

yourAnswerToTheQuestion