Не винаги нормализирането до точката на смърт причинява удари в производителността, но е вярно, че аз лично не прилагам същата нормализация към MongoDB, както към SQL.
Ако сте запознати с нормализираните форми ( http://en.wikipedia.org/wiki/Database_normalization ) Харесва ми да мисля, че MongoDB отива към 1NF и след това се връща към денормализирано отново.
О, да, ние го правим. Актуализирането е трудно, ако данните са дублирани погрешно.
Нека ви дам пример:category и product биха били две отделни единици, не може да се отрече. Тези два обекта са нормализирани (повтарящите се данни на product е изведен от category ). Друг начин за мислене е:Всички продукти ли ще съществуват само в една категория?
Така че за обекти от най-високо ниво, както можете да видите, същите правила се прилагат относително с 1NF, който лесно се прилага към MongoDB.
Що се отнася до дублирането, вие, разбира се, не бихте искали да съхранявате всеки продукт отделно във всяка категория (отговорих с не на въпроса по-горе), така че естествено бихте искали да разделите категориите и продуктите.
Тук обикновено бихте имали връзка много към много със средна нормализирана таблица. Това е мястото, където може да се намеси денормализирането. Можете да кажете, че дадена категория ще има списък с продукти, които са уникални за тази категория, като такива бихте могли да денормализирате релационната таблица много към много в реда на категорията като списък (или обратното в продуктовия ред). Това няма да генерира дублиране, тъй като този списък е уникален за тази категория (повече от вероятно). Това разбира се означава, че категорията или продуктите ще съдържат списък _id s на свързания ред вместо самия обект.
Има моменти, когато дублирането е необходимо, главно за оптимизация или заобикаляне на липсата на JOIN; това правило важи и за SQL, ако някога сте правили достатъчно голям сайт.
Типичните сценарии за използване на дублиране са полета за агрегиране на статистически данни като споделяния и коментари на публикации във Facebook и може би дори 5-те най-нови коментара на тази публикация също ще бъдат дублирани в реда на публикацията.
Така че не става въпрос за пренебрегване на дизайна на схемата, а по-скоро за настройването й за характеристиките на MongoDB. Обикновено, ако го направите, ще откриете, че естествено проектирате добра схема.
Като допълнителна препратка можете да се обърнете тук:http://docs.mongodb.org/ manual/core/data-modeling
