Detta är mer en konst än en vetenskap. Mongo-dokumentationen om scheman är en bra referens, men här är några saker att tänka på:
-
Lägg i så mycket som möjligt
Glädjen med en dokumentdatabas är att den eliminerar många Joins. Din första instinkt bör vara att placera så mycket du kan i ett enda dokument. Eftersom MongoDB-dokument har struktur och eftersom du effektivt kan fråga inom den strukturen (detta innebär att du kan ta den del av dokumentet som du behöver, så dokumentstorleken borde inte oroa dig särskilt mycket) finns det inget omedelbart behov av att normalisera data som t.ex. du skulle göra i SQL. I synnerhet bör all data som inte är användbar förutom dess överordnade dokument vara en del av samma dokument.
-
Separat data som kan hänvisas till från flera ställen till sin egen samling.
Detta är inte så mycket ett "lagringsutrymme"-problem som det är ett "datakonsistens"-problem. Om många poster kommer att referera till samma data är det mer effektivt och mindre felbenäget att uppdatera en enskild post och spara referenser till den på andra ställen.
-
Överväganden om dokumentstorlek
MongoDB inför en storleksgräns på 4 MB (16 MB med 1,8) för ett enda dokument. I en värld av GB data låter detta lite, men det är också 30 tusen tweets eller 250 typiska Stack Overflow-svar eller 20 flimmerbilder. Å andra sidan är detta mycket mer information än man kanske vill presentera på en gång på en vanlig webbsida. Fundera först på vad som kommer att göra dina frågor lättare. I många fall kommer oro för dokumentstorlekar att vara för tidig optimering.
-
Komplexa datastrukturer:
MongoDB kan lagra godtyckliga djupkapslade datastrukturer, men kan inte söka i dem effektivt. Om din data bildar ett träd, en skog eller en graf, behöver du faktiskt lagra varje nod och dess kanter i ett separat dokument. (Observera att det finns datalager speciellt utformade för denna typ av data som man också bör överväga)
Det har också påpekats att det är omöjligt att returnera en delmängd av element i ett dokument. Om du behöver välja och välja några bitar av varje dokument blir det lättare att separera dem.
-
Datakonsistens
MongoDB gör en avvägning mellan effektivitet och konsekvens. Regeln är att ändringar av ett enstaka dokument alltid är atomär, medan uppdateringar av flera dokument aldrig bör antas vara atomära. Det finns inte heller något sätt att "låsa" en post på servern (du kan bygga in detta i klientens logik med till exempel ett "lås"-fält). När du utformar ditt schema, överväg hur du kommer att hålla din data konsekvent. Generellt gäller att ju mer du har i ett dokument desto bättre.
För det du beskriver skulle jag bädda in kommentarerna och ge varje kommentar ett id-fält med ett ObjectID. Objekt-ID:t har en tidsstämpel inbäddad i det så att du kan använda det istället för att skapas på om du vill.