MongoDB nie ma kaskadowych usunięć. Gdy aplikacja usuwa dane, jest również odpowiedzialna za usunięcie wszelkich obiektów, do których istnieją odniesienia, oraz wszelkich odniesień do usuniętego dokumentu. Ale zwykle, gdy używasz on delete w relacyjnej bazie danych mamy przypadek kompozycji, w której jeden obiekt nadrzędny jest właścicielem jednego lub więcej obiektów podrzędnych, a obiekty podrzędne są bez znaczenia bez rodzica. W takiej sytuacji MongoDB zachęca do osadzania zamiast odwoływania się . Oznacza to, że tworzysz tablicę w obiekcie nadrzędnym i umieszczasz w niej kompletne dokumenty podrzędne, zamiast przechowywać je we własnej kolekcji. W ten sposób zostaną usunięte razem z rodzicem, ponieważ są jego częścią.
Chociaż utrzymywanie więcej niż jednej wartości w polu jest absolutnie nie do przyjęcia w SQL, nie ma w tym nic złego w MongoDB. Dzieje się tak, ponieważ język zapytań MongoDB może z łatwością pracować z tablicami i osadzonymi obiektami. Możesz nawet tworzyć indeksy na polach dokumentów podrzędnych w tablicach, dzięki czemu możesz łatwo wyszukiwać obiekty osadzone w innych obiektach.
Jeśli nadal chcesz odwoływać się do obiektów z innej kolekcji, możesz użyć DBRef lub innego unikalnego identyfikatora (unikalność jest jedną z niewielu rzeczy, które MongoDB może wymusić. Aby to zrobić, utwórz unikalny indeks za pomocą polecenia createIndex ). Ale MongoDB nie wymusza w tym przypadku spójności. Możesz tworzyć DBRefs, które wskazują na nieistniejące ObjectIds, a gdy dokument, na który wskazuje DBRef, zostanie usunięty, nic się nie stanie. Aplikacja jest odpowiedzialna za upewnienie się, że kiedy usuwa dokument, wszystkie dokumenty, które się do niego odwołują, są aktualizowane.
MongoDB również nie może narzucać ograniczeń. Nie może nawet wymusić określonego typu pola ze względu na bezschematową naturę MongoDB. Ponownie, twoja aplikacja jest odpowiedzialna za upewnienie się, że dane umieszczane w mongodb są zgodne z określonymi specyfikacjami. Jeśli chcesz to zautomatyzować, dostępne są struktury mapowania obiektowo-relacyjnego dla MongoDB dla wielu języków programowania.
Aby to wszystko podsumować: MongoDB nie jest tak „inteligentny” jak bazy danych SQL. Sama nie robi wiele. Robi to, co każe mu aplikacja, a nie więcej i nie mniej. Ale to jest powód, dla którego jest tak szybki (bez kosztownych kontroli spójności) i elastyczny (bez modyfikacji bazy danych koniecznych do wdrożenia nowych funkcji).
