Memorizzazione dei dati di traduzione come colonna JSON

Lo svantaggio evidente è che se il tuo database non supporta la query su JSON, e in particolare l'indicizzazione su JSON, potresti avere prestazioni inferiori nell'eseguire operazioni diverse da "prendi questo blob di traduzioni" - specialmente "recupera solo" EE " traduzioni ", o" dimmi cosa non ha una traduzione "EE".

Il vantaggio principale dell'archiviazione di JSON è che puoi servirlo molto più velocemente: ricerca chiave, colonna di lettura, dump al browser. Non c'è bisogno di futz con la codifica su JSON al volo - ottieni lo stesso vantaggio che offri ai contenuti dei contenuti statici pre-compressi piuttosto che alla compressione gzip al volo.

Puoi anche bilanciare i due: utilizzare il modello strutturato con la tabella dei collegamenti per preservare le funzionalità di query, ma memorizzare i dati JSON per minimizzare i costi di codifica e decodifica quando si inviano.

In definitiva, dipende da quali query sono più e meno comuni nello spazio dei problemi.

(Oh, e non dimenticare di pensare a cosa succede se due lingue vengono caricate contemporaneamente, se impacchetta tutto nella colonna.)

Non vedo alcun motivo per archiviare JSON direttamente nel database. Come menzionato in una discussione precedente, non è possibile interrogare direttamente il database e i guadagni in termini di prestazioni sono insignificanti. La creazione di JSON programmaticamente dal database sarà insignificante rispetto al tempo necessario per colpire effettivamente il database e la query (sia per la query per JSON che per l'utilizzo di SQL standard)