Това е повече изкуство, отколкото наука. Документацията на Mongo за схемите е добра справка, но ето някои неща, които трябва да имате предвид:
-
Поставете колкото е възможно повече
Радостта на базата данни с документи е, че елиминира много присъединявания. Първият ви инстинкт трябва да бъде да поставите колкото се може повече в един документ. Тъй като документите на MongoDB имат структура и тъй като можете ефективно да правите заявки в рамките на тази структура (това означава, че можете да вземете частта от документа, от която се нуждаете, така че размерът на документа не трябва да ви притеснява много), няма незабавна нужда от нормализиране на данни като бихте направили в SQL. По-специално всички данни, които не са полезни освен основния документ, трябва да бъдат част от същия документ.
-
Отделете данни, които могат да бъдат препратени от множество места, в собствена колекция.
Това не е толкова проблем с „пространството за съхранение“, колкото проблем с „последователността на данните“. Ако много записи ще се отнасят до едни и същи данни, е по-ефективно и по-малко податливо на грешки да актуализирате един запис и да запазите препратките към него на други места.
-
Съображения за размера на документа
MongoDB налага ограничение от 4MB (16MB с 1.8) за един документ. В свят от GB данни това звучи малко, но също така е 30 хиляди туитове или 250 типични отговора на Stack Overflow или 20 трептящи снимки. От друга страна, това е много повече информация, отколкото човек би искал да представи наведнъж на типична уеб страница. Първо помислете какво ще улесни вашите запитвания. В много случаи притесненията относно размерите на документа ще бъдат преждевременна оптимизация.
-
Сложни структури от данни:
MongoDB може да съхранява произволни дълбоко вложени структури от данни, но не може да ги търси ефективно. Ако вашите данни образуват дърво, гора или графика, ефективно трябва да съхранявате всеки възел и неговите ръбове в отделен документ. (Обърнете внимание, че има хранилища за данни, специално проектирани за този тип данни, които също трябва да имате предвид)
Също така беше посочено, че е невъзможно да се върне подмножество от елементи в документ. Ако трябва да подберете и изберете няколко бита от всеки документ, ще бъде по-лесно да ги отделите.
-
Последователност на данните
MongoDB прави компромис между ефективност и последователност. Правилото е промените в един документ винаги атомарни, докато актуализациите на множество документи никога не трябва да се приемат за атомарни. Също така няма начин да "заключите" запис на сървъра (можете да вградите това в логиката на клиента, като използвате например поле "lock"). Когато проектирате вашата схема, помислете как ще поддържате данните си последователни. Като цяло, колкото повече съхранявате в документ, толкова по-добре.
За това, което описвате, бих вградил коментарите и бих дал на всеки коментар поле за идентификатор с ObjectID. ObjectID има времеви печат, вграден в него, така че можете да го използвате вместо създадено в, ако желаете.
