Nie zawsze normalizacja do punktu śmierci powoduje spadki wydajności, ale prawdą jest, że osobiście nie stosuję tej samej normalizacji do MongoDB, co do SQL.
Jeśli znasz znormalizowane formularze ( http://en.wikipedia.org/wiki/Database_normalization ) Lubię myśleć, że MongoDB przechodzi do 1NF, a następnie wraca do stanu denormalizacji.
O tak, robimy. Aktualizacja jest uciążliwa, jeśli dane są źle zduplikowane.
Podam przykład:category i product byłyby dwoma oddzielnymi podmiotami, nie można temu zaprzeczyć. Te dwie jednostki są znormalizowane (powtarzające się dane product został wydzielony z category ). Inny sposób myślenia to:Czy wszystkie produkty będą istnieć tylko w jednej kategorii?
Tak więc na encjach najwyższego poziomu, jak widać, stosują się te same zasady, a 1NF można łatwo zastosować do MongoDB.
Jeśli chodzi o powielanie, oczywiście nie chciałbyś przechowywać każdego produktu osobno w ramach każdej kategorii (odpowiedziałem „nie” na powyższe pytanie), więc naturalnie chciałbyś oddzielić kategorie i produkty.
Normalnie miałbyś tutaj relację wiele-do-wielu ze średnią znormalizowaną tabelą. Tutaj może wkroczyć denormalizacja. Można powiedzieć, że kategoria będzie miała listę produktów, które są unikalne dla tej kategorii, w związku z czym można zdenormalizować relacyjną tabelę wiele-do-wielu do wiersza kategorii jako listę (lub odwrotnie do rzędu produktów). Nie spowoduje to duplikacji, ponieważ ta lista jest unikalna dla tej kategorii (bardziej niż prawdopodobne). To oczywiście oznacza, że kategoria lub produkty będą zawierać listę _id s powiązanego wiersza zamiast samego obiektu.
Są chwile, w których duplikacja jest konieczna, głównie w celu optymalizacji lub obejścia braku JOIN; ta zasada dotyczy również SQL, jeśli kiedykolwiek stworzyłeś wystarczająco dużą witrynę.
Typowe scenariusze użycia powielania to agregacja pól statystyk, takich jak posty na Facebooku i komentarze, a być może nawet 5 ostatnich komentarzy do tego posta zostanie zduplikowanych w wierszu posta.
Nie chodzi więc o ignorowanie projektu schematu, ale raczej o dostrojenie go pod kątem charakterystyk MongoDB. Zwykle, jeśli to zrobisz, przekonasz się, że oczywiście zaprojektujesz dobry schemat.
Jako dodatkowe odniesienie możesz odwołać się tutaj:http://docs.mongodb.org/ ręczne/rdzeń/modelowanie danych
