La migliore architettura per convertire JSON in SQL?

Question

Mi stavo chiedendo se qualcuno avesse qualche idea sulla conversione di una struttura di database di documenti JSON in SQL. Deve essere fatto per l'integrazione dei dati/il magazzinaggio.

I campi JSON sono relativamente statici, ma i nuovi "campi" possono spuntare ogni 2-4 settimane.

A causa della natura di questo, e la conversione in SQL --- stavo pensando ... analizzare tutti i campi statici in campi SQL. I campi "dinamici" sono strutturati in una parte del documento JSON, per fortuna.

La mia idea era di scaricare semplicemente questa 'sezione campi dinamici' che può contenere 50, 100 campi, che sa - può cambiare lentamente - in un campo SQL aggiuntivo.

In questo modo, almeno il processo ETL è relativamente statico, indipendentemente dal modo in cui i campi JSON cambiano.

Quindi un secondo livello, o forse "vista", essenzialmente analizza questa colonna gigante nei suoi campi separati. Cioè la colonna gigante potrebbe dire "colore: rosso; stato: aperto; città: Roma" ... e una serie di funzioni stringa li analizzerebbe per riempire i campi di colore, stato e città, forse in una vista.

Non sono sicuro che sia pazzesco o no. L'altra opzione sarebbe quella di eseguire istruzioni MySQL al volo (per aggiungere colonne) così come sono incontrate nei documenti JSON, ma questa è la sua serie di problemi.

Qualcuno ha pensieri su questo?

E dire che il database è solo aggiunto, mai aggiornato. In questo caso, l'analisi deve essere eseguita una sola volta per riga. Una vista sarebbe ancora l'opzione migliore? O semplicemente un altro tavolo del tutto?

Answer 1

Strategia semplice: Analizzare i JSON dei campi corretti e di cui si è a conoscenza. Metti questi in tabelle SQL.

Campi che non si riconoscono, lasciarli come JSON. Se il database supporta un tipo JSON, mettilo lì. Altrimenti memorizzalo in un grande campo di stringa.

Non iniziare l'analisi di JSON in campi anonimi, soprattutto quando i campi cambiano su base settimanale (o così). La maggior parte dei database al giorno d'oggi supporta in qualche misura JSON, quindi è possibile utilizzare il motore di database per l'analisi durante la query dei dati.

Answer 2

Sembra che tu abbia un handle sui campi "statici". Hai considerato di utilizzare un sistema di tagging per i campi "dinamici"? Forse una tabella che memorizza un valore, una chiave esterna a un elenco di tag principale (un elenco di tutti i campi "statici" disponibili che contengono definizioni di tipo di valore come string, int, ecc.) E una chiave esterna all'entità il valore del campo è associato con? Dovresti ovviamente mantenere un processo ETL per i tag master noti, ma ciò sembrerebbe semplificare un po 'le cose. Quando vengono aggiunti nuovi tag, è possibile semplicemente introdurre alcune transazioni SQL (auspicabilmente) testate che aggiungono i nuovi tag al sistema e li versioni insieme alla propria applicazione.

Avendo detto tutto ciò probabilmente farei un altro passo indietro e fare qualche altro lavoro di progettazione e trovare una strategia che mantenga le cose coerenti a livello di applicazione in favore del tentativo di farlo sul livello di persistenza. Eventi di dominio DDD +, modelli produttore/consumatore, pub/sub, semantica degli attori o qualche altra strategia che risolve il problema più avanti nello stack. Sembra che la maggior parte di questo possa essere legata ad alcune schermate di manutenzione, mantenendo le cose coerenti a livello di applicazione se si è disposti a riprogettare e ridefinire alcuni dei vostri oggetti/entità aziendali.