Opdateret 4. juni 2017
I betragtning af at dette spørgsmål/svar har vundet en vis popularitet, tænkte jeg, at det var en opdatering værd.
Da dette spørgsmål oprindeligt blev sendt, havde MySQL ingen understøttelse af JSON-datatyper, og supporten i PostgreSQL var i sin vorden. Siden 5.7 understøtter MySQL nu en JSON-datatype (i et binært lagerformat) og PostgreSQL JSONB er blevet markant modnet. Begge produkter leverer effektive JSON-typer, der kan gemme vilkårlige dokumenter, inklusive understøttelse af indeksering af specifikke nøgler til JSON-objektet.
Jeg står dog stadig ved mit oprindelige udsagn om, at din standardpræference, når du bruger en relationsdatabase, stadig skal være kolonne-pr-værdi. Relationelle databaser er stadig bygget på den antagelse, at dataene i dem vil være ret godt normaliserede. Forespørgselsplanlæggeren har bedre optimeringsoplysninger, når du ser på kolonner, end når du ser på nøgler i et JSON-dokument. Fremmednøgler kan oprettes mellem kolonner (men ikke mellem nøgler i JSON-dokumenter). Vigtigt:Hvis størstedelen af dit skema er flygtigt nok til at retfærdiggøre brugen af JSON, vil du måske i det mindste overveje, om en relationsdatabase er det rigtige valg.
Når det er sagt, er få applikationer perfekt relationelle eller dokumentorienterede. De fleste applikationer har en blanding af begge. Her er nogle eksempler, hvor jeg personligt har fundet JSON nyttig i en relationsdatabase:
-
Når du gemmer e-mail-adresser og telefonnumre for en kontakt, hvor det er meget nemmere at administrere dem som værdier i et JSON-array end flere separate tabeller
-
Gemmer vilkårlige nøgle/værdi brugerpræferencer (hvor værdien kan være boolsk, tekstuel eller numerisk, og du ikke ønsker at have separate kolonner for forskellige datatyper)
-
Lagring af konfigurationsdata, der ikke har noget defineret skema (hvis du bygger Zapier eller IFTTT og skal gemme konfigurationsdata for hver integration)
Jeg er sikker på, at der også er andre, men dette er blot et par hurtige eksempler.
Originalt svar
Hvis du virkelig vil være i stand til at tilføje så mange felter, som du vil uden begrænsning (ud over en vilkårlig dokumentstørrelsesgrænse), skal du overveje en NoSQL-løsning såsom MongoDB.
For relationsdatabaser:brug én kolonne pr. værdi. At sætte en JSON-blob i en kolonne gør det praktisk talt umuligt at forespørge (og smerteligt langsom, når du rent faktisk finder en forespørgsel, der virker).
Relationelle databaser udnytter datatyper ved indeksering og er beregnet til at blive implementeret med en normaliseret struktur.
Som en sidebemærkning:dette betyder ikke, at du aldrig skal gemme JSON i en relationsdatabase. Hvis du tilføjer ægte metadata, eller hvis din JSON beskriver oplysninger, der ikke behøver at blive forespurgt og kun bruges til visning, kan det være overkill at oprette en separat kolonne for alle datapunkterne.