EAV-Daten vom Client in ein relationales Modell auf dem Server verschieben

Ich baue eine Softwareplattform für die mobile elektronische Datenerfassung auf. Es sollte jede Art von Daten unterstützen. Zum Beispiel könnte die Regierung es für eine Bevölkerungsumfrage verwenden; Ein produzierendes Unternehmen kann es verwenden, um den Zustand der Anlage in seinen Fabriken zu bewerten. eine Forschungsorganisation könnte es für klinische Studien verwenden, e.t.c

Als solches wird die Software von einer Datenbank mit relationalem Standarddesign für die Metadaten und den Entitätsattributwert für die tatsächlichen Daten angetrieben. Die Client-Software liest dann die Metadaten und rendert die entsprechende Benutzeroberfläche mit Regeln, Überprüfungen, Überspringlogik usw. Ich glaube, dass die Wahl von EAV aufgrund der Vielfalt der Daten, die gesammelt werden könnten, eine gute Wahl ist, aber ...

Nachdem die Daten von den mobilen Clients an den Server des Kunden gesendet wurden, ist das EAV-Modell nicht mehr nützlich, da der Kunde nur seine (normalerweise sehr wenigen) Tabellen zur Visualisierung und Verarbeitung erwartet.

Ich habe zwei Optionen zum Schwenken der Daten in Betracht gezogen.

1) Schwenken Sie die Daten sofort, wenn sie an den Server gesendet werden (über einen JSON-Webdienst), und speichern Sie sie sofort in einem relationalen Modell.

2) Speichern Sie die Daten in einem ähnlichen Schema auf dem Server, aber mit einem Hintergrundprozess, der sie regelmäßig pivotisiert und in einem relationalen Modell speichert.

Die erste Alternative scheint effizienter zu sein, da das Verschieben eines Datensatzes auf einmal offensichtlich schneller und weniger CPU-intensiv ist. Der Nachteil ist, dass bei einer Änderung der Metadaten dieser Prozess sofort angepasst werden muss, indem das relationale Modell für die Daten entsprechend geändert wird. Dies kann je nach Umfang der Änderungen einige Zeit in Anspruch nehmen. Schlimmer noch, wenn dies aus irgendeinem Grund fehlschlägt, werden Upload-Anforderungen möglicherweise abgelehnt. Bei Verwendung des zweiten Ansatzes würde ein solcher Fehler nichts so dringendes "kaputtmachen".

Gibt es noch andere potenzielle Fallstricke, die mir fehlen könnten, oder Überlegungen zum Design, die ich anstellen sollte? Was sind einige gute Gründe, es so oder so zu machen? Gibt es andere Alternativen, nach denen ich suchen sollte, um dieses Problem zu lösen?

Antworten auf die Frage(2)

Ihre Antwort auf die Frage