Wenn es um die Daten / DDL Strukturen geht, wie wär es mit Key Value.
JSON ist es ja egal, was Du wie lang da rein schreibst, aber
SQL eben nicht. Keine Dynamik, außer mit speziellen SP, geht glaub ich auch in
MSSQL, aber ist eine eigene Baustelle,
Daten klassisch in JSON, die 1:1 in eine Table als Datensatz überführt werden können.
[{"id":1,"name":"January"},{"id":2,"name":"February "}]
[{"id":1,"name":"January"},{"id":2,"name":"February "}]
Als KV
[
{"id":1},
{"name":"January"},
{"id":2},
{"name":"February"}],
[
{"id":1},
{"name":"January"},
{"id":2},
{"name":"February"}]
und natürlich egal, welche Attribute:
[
{"bigid":1},
{"Kontextname":"January"},
{"id":2},
{"anderername":"February"}
{"Zusatzattribut":"February"}
]
Hast Du eine konkrete Vorstellung, welche Attribute es sein sollen und wie hoch sagen wir die Deckungsgleichheit bei verschiedenen Tests ist?
Spaß macht
SQL natürlich nur mit festen Strukturen. Man kann aber jedes JSON in eine feste Struktur überführen.
Variante, wenn man 100 Attribute hat, und 70 davon sind sowieso fest, braucht man kein JSON dafür, nur halt ein Feld für "JSON Reste", den variablen Teil. JSON wäre m.E. eine Lösung für die Strecke: Ich mache jetzt schon mal Tests, weiß aber noch nicht, was mich eigentlich interessiert (weil ich das erst bei der Auswertung rausfinde)
Je länger die Tests laufen, desto fester wird die Definition der Daten, die wichtig und demnach statisch ermittelt und analysiert werden. Alles was fest ist, kommt in eine Tabelle, der Rest weiter JSON.
Du kannst also z.B.
CSV loggen mit 70 festen Spalten und einer JSON Spalte, wo der ganze Kram drin steht, der noch unspezifisch ist. Und entsprechend der
CSV auch eine Tabelle haben, die es genauso importiert.