Aggiornato il 4 giugno 2017
Dato che questa domanda/risposta ha guadagnato una certa popolarità, ho pensato che valesse la pena aggiornarla.
Quando questa domanda è stata originariamente postata, MySQL non aveva supporto per i tipi di dati JSON e il supporto in PostgreSQL era agli albori. Dalla versione 5.7, MySQL ora supporta un tipo di dati JSON (in un formato di archiviazione binaria) e PostgreSQL JSONB è maturato in modo significativo. Entrambi i prodotti forniscono tipi JSON performanti in grado di archiviare documenti arbitrari, incluso il supporto per l'indicizzazione di chiavi specifiche dell'oggetto JSON.
Tuttavia, continuo a sostenere la mia affermazione originale secondo cui la tua preferenza predefinita, quando si utilizza un database relazionale, dovrebbe essere ancora colonna per valore. I database relazionali sono ancora costruiti partendo dal presupposto che i dati al loro interno saranno abbastanza ben normalizzati. Il pianificatore di query ha migliori informazioni sull'ottimizzazione quando si guardano le colonne rispetto a quando si guardano le chiavi in un documento JSON. Le chiavi esterne possono essere create tra le colonne (ma non tra le chiavi nei documenti JSON). È importante sottolineare che se la maggior parte del tuo schema è abbastanza volatile da giustificare l'utilizzo di JSON, potresti almeno considerare se un database relazionale è la scelta giusta.
Detto questo, poche applicazioni sono perfettamente relazionali o orientate ai documenti. La maggior parte delle applicazioni ha un mix di entrambi. Ecco alcuni esempi in cui personalmente ho trovato utile JSON in un database relazionale:
-
Quando si archiviano indirizzi e-mail e numeri di telefono per un contatto, dove la loro memorizzazione come valori in un array JSON è molto più facile da gestire rispetto a più tabelle separate
-
Salvataggio delle preferenze utente chiave/valore arbitrarie (dove il valore può essere booleano, testuale o numerico e non vuoi avere colonne separate per diversi tipi di dati)
-
Memorizzazione dei dati di configurazione che non hanno uno schema definito (se stai creando Zapier o IFTTT e devi archiviare i dati di configurazione per ogni integrazione)
Sono sicuro che ce ne sono anche altri, ma questi sono solo alcuni rapidi esempi.
Risposta originale
Se vuoi davvero essere in grado di aggiungere tutti i campi che desideri senza alcuna limitazione (a parte un limite arbitrario della dimensione del documento), prendi in considerazione una soluzione NoSQL come MongoDB.
Per i database relazionali:utilizzare una colonna per valore. L'inserimento di un BLOB JSON in una colonna rende praticamente impossibile eseguire query (e dolorosamente lento quando trovi effettivamente una query che funziona).
I database relazionali sfruttano i tipi di dati durante l'indicizzazione e sono pensati per essere implementati con un normalizzato struttura.
Come nota a margine:questo non vuol dire che non dovresti mai archiviare JSON in un database relazionale. Se stai aggiungendo veri metadati o se il tuo JSON descrive informazioni che non devono essere interrogate ed è utilizzato solo per la visualizzazione, potrebbe essere eccessivo creare una colonna separata per tutti i punti dati.
