JSON in Database Schema Design

Question

JSON in Database Schema Design

#1 da (1 voti)
#2 da (1 voti)

0

Sto lavorando a un'applicazione web con requisiti in costante evoluzione. Le relazioni tra entità nel database sono rimaste per lo più le stesse ma gli attributi di ciascun tipo di entità cambiano molto.

Sto usando Java, JPA e Postgres. Postgres ha un tipo JSON. È un buon progetto per rimuovere tutti gli attributi non chiave e chiave esterna e inserirli in un attributo JSON?

Colonne di FooTable vecchio design Long id String foo Boolean fooCheck Bar bar /**Foreign key ref*/

Colonne di FooTable Nuovo design Long id JSON attributes Bar bar /** Foreign key ref */

I vantaggi che vedo del nuovo design sono

Meno conversioni overhead tra POJO e JSON
Non è necessario modificare lo schema?
Più veloce per testare nuove cose?

Uno svantaggio che vedo è la migrazione di un JSON scaduto. Ci sono potenziali insidie che mi mancano di questo approccio?

java database-design postgres

posta Daniel 24.05.2018 - 14:35

fonte

2 risposte

Leggi altre domande sui tag java database-design postgres

Iniezione delle dipendenze in un metodo con altri parametri del metodo Conversione implicita per la sottotipizzazione della funzione

score 1 · Answer 1

Trovati alcuni post utili sul blog

TL; DR È accettabile utilizzare JSON se i dati sono isolati. Può essere difficile migrare i dati JSON. Le prestazioni di JOIN sono molto lente.

score 1 · Answer 2

Mettere gli attributi in un campo JSON è come spazzare via il problema sotto il tappeto. Concettualmente stai ancora cambiando lo schema se aggiungi, rimuovi o modifichi gli attributi - devi ancora cambiare codice facendo affidamento su questi attributi e devi aggiornare tutte le query che si basano su questi attributi. Semplicemente non hai il database per verificare che tu stia rispettando lo schema, quindi hai un rischio molto più elevato di introdurre bug e subirai una pesante penalizzazione delle prestazioni quando esegui una query su questi attributi.

Se si tratta di un problema che modifica lo schema del database tutte le volte che lo si desidera, è consigliabile analizzare la procedura di distribuzione con migrazioni o simili. Poiché hai "requisiti in continua evoluzione", sarebbe utile investire tempo nell'ottimizzazione della distribuzione delle modifiche per ridurre al minimo l'attrito.

Detto questo, ci sono casi d'uso in cui un campo JSON è appropriato, ad esempio se i dati sono opachi all'applicazione back-end e utilizzati solo da plug-in di terze parti, o se si stanno solo registrando dati non letti di nuovo dall'applicazione. Ma questo non sembra essere il caso qui.