MongoDB normalizacja, klucz obcy i łączenie

Zanim zanurzę się naprawdę głęboko w MongoDB przez kilka dni, pomyślałem, że zadam dość podstawowe pytanie, Czy powinienem w ogóle nurkować, czy nie. W zasadzie nie mam doświadczenia z nosql.

Przeczytałem trochę o niektórych zaletach baz danych dokumentów i myślę, że dla tej nowej aplikacji będą one naprawdę świetne. Zawsze jest kłopotliwe Robienie ulubionych, komentarzy itp. dla wielu typów obiektów (wiele relacji m-do-m) i podklas - to rodzaj bólu do czynienia z.

Mam też strukturę, która będzie bolało definiować w SQL, ponieważ jest bardzo zagnieżdżona i przekłada się na dokument o wiele lepiej niż 15 różnych tabel.

Ale jestem zdezorientowany co do kilku rzeczy.

  1. Czy pożądane jest utrzymanie znormalizowanej bazy danych? Naprawdę nie chcę aktualizować wielu rekordów. Czy nadal tak ludzie podchodzą do projektowania bazy danych w MongoDB?

  2. Co się dzieje, gdy użytkownik faworyzuje książkę i ten wybór jest nadal przechowywany w dokumencie użytkownika, ale następnie książka jest usuwana? Jak związek zostaje odłączony bez obcych kluczy? Czy osobiście jestem odpowiedzialny za usunięcie wszystkich linków?

  3. Co się stanie, jeśli użytkownik wybierze książkę, której już nie ma, a ja ją odpytam (jakiś join)? Czy muszę tu tolerować błędy?

Author: Community, 2011-04-30
Source

2 answers

MongoDB nie obsługuje relacji kluczy obcych po stronie serwera, normalizacja jest również zniechęcana. Jeśli to możliwe, należy osadzić obiekt potomny w obiektach nadrzędnych, co zwiększy wydajność i sprawi, że klucze obce będą całkowicie niepotrzebne. Jednak nie zawsze jest to możliwe, dlatego istnieje specjalna konstrukcja o nazwie DBRef, która pozwala odwoływać się do obiektów w innym zbiorze. Może to nie być tak szybkie, ponieważ DB musi wykonywać dodatkowe zapytania do odczytu obiektów, ale pozwala na rodzaj odniesienia do klucza obcego.

Nadal będziesz musiał obsługiwać swoje referencje ręcznie. Tylko podczas wyszukiwania DBRef zobaczysz, czy istnieje, DB nie przejrzy wszystkich dokumentów, aby szukać odniesień i usunąć je, jeśli cel odniesienia już nie istnieje. Ale myślę, że usunięcie wszystkich odniesień po usunięciu książki wymagałoby jednego zapytania na kolekcję, nie więcej, więc nie tak trudne naprawdę.

Jeśli twój schemat jest bardziej złożony to prawdopodobnie powinieneś wybrać relacyjną bazę danych, a nie nosql.

Istnieje również książka o projektowaniu baz danych MongoDB: projekt dokumentu dla MongoDB

UPDATE powyższa książka nie jest już dostępna, jednak ze względu na popularność MongoDB istnieje sporo innych. Nie będę łączył ich wszystkich, ponieważ takie linki mogą się zmienić, proste wyszukiwanie na Amazon pokazuje wiele stron, więc nie powinno być problemu, aby znaleźć niektóre.

Zobacz instrukcję MongoDB strona dla 'manual references' i DBRefs dla dalszych szczegółów i przykładów

 63
Author: Tomasz Stanczak,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-06-14 05:13:18

Powyżej, @ TomaaszStanczak stwierdza

MongoDB nie obsługuje relacji kluczy obcych po stronie serwera, odradzana jest również normalizacja. Należy osadzić obiekt potomny wewnątrz obiektów nadrzędnych, jeśli to możliwe, zwiększy to wydajność i zrób klucze obce całkowicie niepotrzebne. To powiedziawszy nie zawsze jest możliwe ...

Normalizacja nie jest zniechęcana przez Mongo. Żeby było jasne, mówimy o dwóch zasadniczo różnych rodzajach relacji dwa podmioty danych mogą mieć. W jednym, jedna jednostka potomna jest własnością wyłącznie przez obiekt nadrzędny. W tego typu relacjach sposobem Mongo jest osadzenie.

W drugiej klasie relacji dwa byty istnieją niezależnie-mają niezależne życia i relacje. Mongo pragnie, aby ten rodzaj relacji nie istniał i frustrująco milczy na temat tego, jak sobie z tym poradzić. Osadzanie nie jest rozwiązaniem. Normalizacja nie jest zniechęcana ani zachęcana. Mongo just daje dwa mechanizmy radzenia sobie z tym; Manual refs (analogiczny do klucza z ograniczeniem klucza obcego wiążącego dwie tabele) i DBRef (inny, nieco bardziej ustrukturyzowany sposób robienia tego samego). W tym przypadku zastosowanie baz danych SQL win.

 17
Author: Francis M. Bacon,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-01-16 09:34:29