Najlepsza architektura do konwersji JSON na SQL?

Question

Po prostu zastanawiałem się, czy ktoś ma jakieś przemyślenia na temat konwersji struktury bazy danych JSON-document na SQL. Trzeba to zrobić dla integracji danych/magazynowania.

Pola JSON są stosunkowo statyczne, ale nowe "pola" mogą pojawiać się co 2-4 tygodnie.

Z powodu charakteru tego i konwersji do SQL --- myślałem ... przetworzyć wszystkie statyczne pola na pola SQL. Pola "dynamiczne" są na szczęście podzielone na część dokumentu JSON.

Moim pomysłem było po prostu zrzucić tę "sekcję pól dynamicznych", która może pomieścić 50, 100 pól, kto wie - może się powoli zmieniać - w jedno dodatkowe pole SQL.

W ten sposób przynajmniej proces ETL jest stosunkowo statyczny, niezależnie od tego, jak zmienia się pole JSON.

Następnie druga warstwa, a może "widok" w istocie sparowałaby tę gigantyczną kolumnę w oddzielne pola. IE gigantyczna kolumna mogłaby powiedzieć "kolor: czerwony, status: otwarty, miasto: Rzym" ... a seria funkcji łańcuchowych przeanalizowałaby je, aby wypełnić kolor, status i pola miasta, być może w widoku.

Nie jestem pewien, czy to jest szalone myślenie, czy nie. Inną opcją byłoby wykonywanie instrukcji MySQL w locie (w celu dodania kolumn), jakie napotkano w dokumentach JSON, ale to jest własny zestaw problemów.

Ktoś myśli na ten temat?

Powiedzmy, że baza danych została dodana do, nigdy nie zaktualizowana. W takim przypadku "parsowanie" należy wykonać tylko raz w rzędzie. Czy widok nadal będzie najlepszą opcją? A może po prostu inny stół?

Answer 1

Prosta strategia: Parsuj z JSON pola, które są ustalone i o których wiesz. Umieść je w tabelach SQL.

Pola, których nie rozpoznajesz, pozostaw je jako JSON. Jeśli baza danych obsługuje typ JSON, umieść go tam. W przeciwnym razie przechowuj go w dużym polu tekstowym.

Nie rozpoczynaj analizowania JSON w anonimowych polach, szczególnie gdy pola zmieniają się co tydzień (lub tak). Większość baz danych obsługuje obecnie JSON w pewnym stopniu, więc można użyć silnika bazy danych do analizowania podczas wysyłania zapytań do danych.

Answer 2

Wygląda na to, że masz uchwyt na polach "statycznych". Czy rozważałeś zastosowanie systemu znakowania dla pól "dynamicznych"? Być może tabela, która przechowuje wartość, klucz obcy do głównej listy znaczników (lista wszystkich dostępnych "statycznych" pól, które zawiera definicje typów wartości, takich jak string, int, itp.) I klucz obcy do encji, do której przypisana jest wartość pola z? Oczywiście trzeba by było zachować proces ETL dla znanych znaczników głównych, ale wydaje się, że trochę to upraszcza. Po dodaniu nowych tagów można po prostu wprowadzić niektóre (mam nadzieję) przetestowane transakcje SQL, które dodadzą nowe znaczniki do systemu i będą wersją wraz z aplikacją.

Powiedziawszy to wszystko, prawdopodobnie zrobiłabym jeszcze trochę więcej pracy i wykonałabym więcej prac projektowych i opracowałabym strategię, która zachowuje spójność w warstwie aplikacji na rzecz próbowania w warstwie trwałości. Zdarzenia domeny DDD +, modele producenta/konsumenta, pub/sub, semantyka aktora lub inna strategia, która rozwiązuje problem, zwiększając swój stack. Wygląda na to, że większość z tego może być związana z niektórymi ekranami konserwacji, aby zachować spójność w warstwie aplikacji, jeśli chcesz dokonać przeprojektowania i przedefiniować niektóre obiekty biznesowe/podmioty.