Dette er mere en kunst end en videnskab. Mongo-dokumentationen om skemaer er en god reference, men her er nogle ting at overveje:
-
Læg så meget ind som muligt
Glæden ved en dokumentdatabase er, at den eliminerer mange Joins. Dit første instinkt bør være at placere så meget i et enkelt dokument, som du kan. Fordi MongoDB-dokumenter har struktur, og fordi du effektivt kan forespørge inden for den struktur (dette betyder, at du kan tage den del af dokumentet, du har brug for, så dokumentstørrelsen burde ikke bekymre dig meget), er der ikke noget umiddelbart behov for at normalisere data som f.eks. du ville i SQL. Især alle data, der ikke er nyttige bortset fra dets overordnede dokument, bør være en del af det samme dokument.
-
Separat data, der kan henvises til fra flere steder i sin egen samling.
Dette er ikke så meget et "lagerplads"-problem, som det er et "datakonsistens". Hvis mange poster vil referere til de samme data, er det mere effektivt og mindre fejltilbøjeligt at opdatere en enkelt post og opbevare referencer til den andre steder.
-
Overvejelser om dokumentstørrelse
MongoDB pålægger en størrelsesgrænse på 4 MB (16 MB med 1,8) på et enkelt dokument. I en verden med GB data lyder dette lille, men det er også 30 tusinde tweets eller 250 typiske Stack Overflow-svar eller 20 flimmerbilleder. På den anden side er dette langt mere information, end man måske ønsker at præsentere på én gang på en typisk webside. Overvej først, hvad der vil gøre dine forespørgsler lettere. I mange tilfælde vil bekymring for dokumentstørrelser være for tidlig optimering.
-
Komplekse datastrukturer:
MongoDB kan gemme vilkårlige dybe indlejrede datastrukturer, men kan ikke søge i dem effektivt. Hvis dine data danner et træ, en skov eller en graf, skal du effektivt gemme hver node og dens kanter i et separat dokument. (Bemærk, at der er datalagre specielt designet til denne type data, som man også bør overveje)
Det er også blevet påpeget, at det er umuligt at returnere en delmængde af elementer i et dokument. Hvis du har brug for at vælge-og-vælge et par stykker af hvert dokument, vil det være nemmere at adskille dem.
-
Datakonsistens
MongoDB foretager en afvejning mellem effektivitet og konsistens. Reglen er, at ændringer af et enkelt dokument altid er atomisk, mens opdateringer til flere dokumenter aldrig bør antages at være atomare. Der er heller ingen måde at "låse" en post på serveren (du kan bygge denne ind i klientens logik ved at bruge f.eks. et "lås" felt). Når du designer dit skema, skal du overveje, hvordan du vil holde dine data konsistente. Generelt, jo mere du gemmer i et dokument, jo bedre.
Til det du beskriver, ville jeg indlejre kommentarerne og give hver kommentar et id-felt med et ObjectID. Objekt-ID'et har et tidsstempel indlejret i det, så du kan bruge det i stedet for at oprette det på, hvis du vil.