Dit is meer een kunst dan een wetenschap. De Mongo-documentatie over schema's is een goede referentie, maar hier zijn enkele dingen om te overwegen:
-
Doe er zoveel mogelijk in
Het leuke van een Document-database is dat het veel Joins elimineert. Je eerste instinct zou moeten zijn om zoveel mogelijk in één document te plaatsen. Omdat MongoDB-documenten een structuur hebben en omdat u binnen die structuur efficiënt query's kunt uitvoeren (dit betekent dat u het deel van het document kunt nemen dat u nodig hebt, dus u hoeft zich geen zorgen te maken over de documentgrootte), hoeft u niet onmiddellijk gegevens te normaliseren zoals je zou in SQL. In het bijzonder moeten alle gegevens die behalve het bovenliggende document niet nuttig zijn, deel uitmaken van hetzelfde document.
-
Scheid gegevens waarnaar op meerdere plaatsen kan worden verwezen in een eigen verzameling.
Dit is niet zozeer een kwestie van "opslagruimte", maar een kwestie van "gegevensconsistentie". Als veel records naar dezelfde gegevens verwijzen, is het efficiënter en minder foutgevoelig om één record bij te werken en verwijzingen ernaar op andere plaatsen te bewaren.
-
Overwegingen voor documentgrootte
MongoDB legt een limiet van 4 MB (16 MB met 1.8) op voor een enkel document. In een wereld van GB aan data klinkt dit weinig, maar het zijn ook 30 duizend tweets of 250 typische Stack Overflow-antwoorden of 20 flikkerende foto's. Aan de andere kant is dit veel meer informatie dan men in één keer op een typische webpagina zou willen presenteren. Bedenk eerst wat uw vragen gemakkelijker zal maken. In veel gevallen zal bezorgdheid over documentformaten een voortijdige optimalisatie zijn.
-
Complexe datastructuren:
MongoDB kan willekeurige diep geneste datastructuren opslaan, maar kan ze niet efficiënt doorzoeken. Als uw gegevens een boom, bos of grafiek vormen, moet u in feite elk knooppunt en zijn randen in een afzonderlijk document opslaan. (Merk op dat er datastores zijn die speciaal voor dit type data zijn ontworpen en waar je ook rekening mee moet houden)
Er is ook op gewezen dat het onmogelijk is om een subset van elementen in een document terug te geven. Als u een paar stukjes van elk document moet kiezen, is het gemakkelijker om ze te scheiden.
-
Gegevensconsistentie
MongoDB maakt een afweging tussen efficiëntie en consistentie. De regel is dat wijzigingen aan een enkel document altijd . zijn atomic, terwijl updates van meerdere documenten nooit als atomic mogen worden aangenomen. Er is ook geen manier om een record op de server te "vergrendelen" (u kunt dit inbouwen in de logica van de client met bijvoorbeeld een "vergrendel"-veld). Bedenk bij het ontwerpen van uw schema hoe u uw gegevens consistent houdt. Over het algemeen geldt:hoe meer u in een document bewaart, hoe beter.
Voor wat je beschrijft, zou ik de opmerkingen insluiten en elke opmerking een id-veld geven met een ObjectID. De ObjectID heeft een ingebedde tijdstempel, zodat je die kunt gebruiken in plaats van aangemaakt op als je wilt.