To je spíše umění než věda. Mongo Documentation on Schemas je dobrá reference, ale zde je několik věcí, které je třeba zvážit:
-
Vložte co nejvíce
Radost z databáze dokumentů je, že eliminuje spoustu spojení. Vaším prvním instinktem by mělo být umístit do jednoho dokumentu co nejvíce. Protože dokumenty MongoDB mají strukturu a protože v rámci této struktury můžete efektivně dotazovat (to znamená, že si můžete vzít část dokumentu, kterou potřebujete, takže velikost dokumentu by vás neměla příliš znepokojovat), není potřeba okamžitě normalizovat data jako byste v SQL. Zejména jakákoli data, která nejsou užitečná kromě jejich nadřazeného dokumentu, by měla být součástí stejného dokumentu.
-
Oddělte data, na která lze odkazovat z více míst, do vlastní sbírky.
Nejde ani tak o problém „úložného prostoru“, jako spíše o problém „konzistence dat“. Pokud bude mnoho záznamů odkazovat na stejná data, je efektivnější a méně náchylné k chybám aktualizovat jeden záznam a uchovávat odkazy na něj na jiných místech.
-
Úvahy o velikosti dokumentu
MongoDB ukládá limit velikosti 4 MB (16 MB s 1,8) na jeden dokument. Ve světě GB dat to zní málo, ale je to také 30 tisíc tweetů nebo 250 typických odpovědí Stack Overflow nebo 20 blikajících fotografií. Na druhou stranu je to mnohem více informací, než by člověk chtěl najednou prezentovat na typické webové stránce. Nejprve zvažte, co vám usnadní vaše dotazy. V mnoha případech bude obava o velikosti dokumentů předčasnou optimalizací.
-
Složité datové struktury:
MongoDB může ukládat libovolné hluboce vnořené datové struktury, ale nedokáže v nich efektivně vyhledávat. Pokud vaše data tvoří strom, doménovou strukturu nebo graf, potřebujete efektivně uložit každý uzel a jeho okraje v samostatném dokumentu. (Všimněte si, že existují úložiště dat speciálně navržená pro tento typ dat, která je také třeba zvážit.)
Bylo také zdůrazněno, že není možné vrátit podmnožinu prvků v dokumentu. Pokud potřebujete vybrat a vybrat několik kousků z každého dokumentu, bude snazší je oddělit.
-
Konzistence dat
MongoDB dělá kompromis mezi efektivitou a konzistencí. Pravidlem je, že změny v jednom dokumentu jsou vždy atomické, zatímco aktualizace více dokumentů by nikdy neměly být považovány za atomické. Neexistuje také žádný způsob, jak "uzamknout" záznam na serveru (můžete to zabudovat do logiky klienta pomocí například pole "lock"). Při navrhování schématu zvažte, jak zajistíte konzistentnost dat. Obecně platí, že čím více toho v dokumentu uchováte, tím lépe.
Pro to, co popisujete, bych vložil komentáře a dal každému komentáři pole id s ObjectID. ObjectID má v sobě vloženou časovou značku, takže ji můžete použít namísto vytvoření v, pokud chcete.