To bardziej sztuka niż nauka. Dokumentacja Mongo na temat schematów jest dobrym punktem odniesienia, ale oto kilka rzeczy do rozważenia:
-
Włóż jak najwięcej
Radość z bazy danych dokumentów polega na tym, że eliminuje ona wiele złączeń. Twoim pierwszym odruchem powinno być umieszczenie jak najwięcej w jednym dokumencie. Ponieważ dokumenty MongoDB mają strukturę i możesz efektywnie wykonywać zapytania w ramach tej struktury (oznacza to, że możesz wziąć część dokumentu, której potrzebujesz, więc rozmiar dokumentu nie powinien Cię zbytnio martwić), nie ma natychmiastowej potrzeby normalizacji danych, takich jak zrobiłbyś to w SQL. W szczególności wszelkie dane, które nie są przydatne poza dokumentem nadrzędnym, powinny być częścią tego samego dokumentu.
-
Oddziel dane, do których można się odwoływać z wielu miejsc, we własnej kolekcji.
Jest to nie tyle kwestia „przestrzeni pamięci”, co kwestia „spójności danych”. Jeśli wiele rekordów będzie odnosić się do tych samych danych, bardziej wydajne i mniej podatne na błędy jest aktualizowanie jednego rekordu i przechowywanie odniesień do niego w innych miejscach.
-
Uwagi dotyczące rozmiaru dokumentu
MongoDB nakłada limit rozmiaru 4 MB (16 MB z 1,8) na pojedynczy dokument. W świecie GB danych brzmi to mało, ale to także 30 tysięcy tweetów lub 250 typowych odpowiedzi na Stack Overflow lub 20 migoczących zdjęć. Z drugiej strony jest to znacznie więcej informacji, niż można by chcieć jednorazowo przedstawić na typowej stronie internetowej. Najpierw zastanów się, co ułatwi Twoje zapytania. W wielu przypadkach obawy o rozmiary dokumentów będą powodowały przedwczesną optymalizację.
-
Złożone struktury danych:
MongoDB może przechowywać dowolne głęboko zagnieżdżone struktury danych, ale nie może ich skutecznie przeszukiwać. Jeśli Twoje dane tworzą drzewo, las lub wykres, faktycznie musisz przechowywać każdy węzeł i jego krawędzie w osobnym dokumencie. (Pamiętaj, że istnieją magazyny danych specjalnie zaprojektowane dla tego typu danych, które również należy wziąć pod uwagę)
Zwrócono również uwagę, że nie jest możliwe zwrócenie podzbioru elementów w dokumencie. Jeśli musisz wybrać kilka fragmentów każdego dokumentu, łatwiej będzie je oddzielić.
-
Spójność danych
MongoDB dokonuje kompromisu między wydajnością a spójnością. Zasadą jest, że zmiany w pojedynczym dokumencie są zawsze atomic, podczas gdy aktualizacje wielu dokumentów nigdy nie powinny być traktowane jako atomic. Nie ma też możliwości "zablokowania" rekordu na serwerze (można to wbudować w logikę klienta używając np. pola "lock"). Podczas projektowania schematu zastanów się, w jaki sposób zachowasz spójność danych. Ogólnie rzecz biorąc, im więcej trzymasz w dokumencie, tym lepiej.
W przypadku tego, co opisujesz, osadzałbym komentarze i nadawał każdemu komentarzowi pole identyfikatora z identyfikatorem obiektu. ObjectID ma osadzony znacznik czasu, więc możesz go użyć zamiast tworzyć w, jeśli chcesz.
