Bijgewerkt op 4 juni 2017
Aangezien deze vraag/het antwoord wat aan populariteit heeft gewonnen, vond ik het een update waard.
Toen deze vraag oorspronkelijk werd gepost, had MySQL geen ondersteuning voor JSON-gegevenstypen en stond de ondersteuning in PostgreSQL nog in de kinderschoenen. Sinds 5.7 ondersteunt MySQL nu een JSON-gegevenstype (in een binair opslagformaat), en PostgreSQL JSONB aanzienlijk volwassen is geworden. Beide producten bieden krachtige JSON-typen die willekeurige documenten kunnen opslaan, inclusief ondersteuning voor het indexeren van specifieke sleutels van het JSON-object.
Ik blijf echter bij mijn oorspronkelijke verklaring dat uw standaardvoorkeur, wanneer u een relationele database gebruikt, nog steeds kolom-per-waarde moet zijn. Relationele databases worden nog steeds gebouwd in de veronderstelling dat de gegevens erin redelijk goed genormaliseerd zullen zijn. De queryplanner heeft betere optimalisatie-informatie bij het bekijken van kolommen dan bij het bekijken van sleutels in een JSON-document. Externe sleutels kunnen tussen kolommen worden gemaakt (maar niet tussen sleutels in JSON-documenten). Belangrijk:als het grootste deel van uw schema vluchtig genoeg is om het gebruik van JSON te rechtvaardigen, kunt u op zijn minst overwegen of een relationele database de juiste keuze is.
Dat gezegd hebbende, er zijn maar weinig applicaties die perfect relationeel of documentgericht zijn. De meeste toepassingen hebben een combinatie van beide. Hier zijn enkele voorbeelden waarbij ik JSON persoonlijk nuttig vond in een relationele database:
-
Bij het opslaan van e-mailadressen en telefoonnummers voor een contactpersoon, waarbij het opslaan als waarden in een JSON-array veel gemakkelijker te beheren is dan meerdere afzonderlijke tabellen
-
Willekeurige sleutel/waarde gebruikersvoorkeuren opslaan (waarbij de waarde booleaans, tekstueel of numeriek kan zijn en u geen aparte kolommen wilt hebben voor verschillende gegevenstypen)
-
Configuratiegegevens opslaan zonder gedefinieerd schema (als u Zapier of IFTTT bouwt en configuratiegegevens voor elke integratie moet opslaan)
Ik weet zeker dat er ook andere zijn, maar dit zijn slechts een paar snelle voorbeelden.
Oorspronkelijk antwoord
Als je echt zoveel velden wilt kunnen toevoegen als je wilt, zonder beperking (behalve een willekeurige limiet voor de documentgrootte), overweeg dan een NoSQL-oplossing zoals MongoDB.
Voor relationele databases:gebruik één kolom per waarde. Door een JSON-blob in een kolom te plaatsen, is het vrijwel onmogelijk om een zoekopdracht uit te voeren (en pijnlijk traag als je daadwerkelijk een zoekopdracht vindt die werkt).
Relationele databases maken gebruik van gegevenstypen bij het indexeren en zijn bedoeld om te worden geïmplementeerd met een genormaliseerde structuur.
Even terzijde:dit wil niet zeggen dat je JSON nooit in een relationele database moet opslaan. Als u echte metadata toevoegt, of als uw JSON informatie beschrijft die niet hoeft te worden opgevraagd en alleen wordt gebruikt voor weergave, kan het overkill zijn om een aparte kolom te maken voor alle datapunten.