Uppdaterad 4 juni 2017
Med tanke på att den här frågan/svaret har blivit lite populärt tyckte jag att det var värt en uppdatering.
När denna fråga ursprungligen postades hade MySQL inget stöd för JSON-datatyper och stödet i PostgreSQL var i sin linda. Sedan 5.7 stöder MySQL nu en JSON-datatyp (i ett binärt lagringsformat) och PostgreSQL JSONB har mognat avsevärt. Båda produkterna tillhandahåller presterande JSON-typer som kan lagra godtyckliga dokument, inklusive stöd för att indexera specifika nycklar för JSON-objektet.
Jag står dock fortfarande vid mitt ursprungliga uttalande att din standardinställning, när du använder en relationsdatabas, fortfarande ska vara kolumn-per-värde. Relationsdatabaser bygger fortfarande på antagandet att data i dem kommer att vara ganska väl normaliserade. Frågeplaneraren har bättre optimeringsinformation när man tittar på kolumner än när man tittar på nycklar i ett JSON-dokument. Främmande nycklar kan skapas mellan kolumner (men inte mellan nycklar i JSON-dokument). Viktigt:om majoriteten av ditt schema är tillräckligt flyktigt för att motivera användningen av JSON, kanske du åtminstone vill överväga om en relationsdatabas är rätt val.
Som sagt, få applikationer är perfekt relations- eller dokumentorienterade. De flesta applikationer har en blandning av båda. Här är några exempel där jag personligen har funnit JSON användbart i en relationsdatabas:
-
När du lagrar e-postadresser och telefonnummer för en kontakt, där lagring av dem som värden i en JSON-matris är mycket lättare att hantera än flera separata tabeller
-
Sparar godtyckliga nyckel/värde användarinställningar (där värdet kan vara booleskt, textuellt eller numeriskt och du inte vill ha separata kolumner för olika datatyper)
-
Lagra konfigurationsdata som inte har något definierat schema (om du bygger Zapier eller IFTTT och behöver lagra konfigurationsdata för varje integration)
Jag är säker på att det finns andra också, men det här är bara några snabba exempel.
Originalt svar
Om du verkligen vill kunna lägga till så många fält du vill utan begränsning (förutom en godtycklig gräns för dokumentstorlek), överväg en NoSQL-lösning som MongoDB.
För relationsdatabaser:använd en kolumn per värde. Att placera en JSON-blobb i en kolumn gör det praktiskt taget omöjligt att fråga (och smärtsamt långsam när du faktiskt hittar en fråga som fungerar).
Relationsdatabaser drar fördel av datatyper vid indexering och är avsedda att implementeras med en normaliserad struktur.
Som en sidoanteckning:detta betyder inte att du aldrig ska lagra JSON i en relationsdatabas. Om du lägger till sann metadata, eller om din JSON beskriver information som inte behöver frågas och endast används för visning, kan det vara överdrivet att skapa en separat kolumn för alla datapunkter.