Właśnie zacząłem używać bazy danych opartej na dokumentach NoSQL (MongoDB) i jestem ciekawy najlepszych praktyk w zakresie projektowania baz danych.
Zakładam, że architektura powinna różnić się od relacyjnych baz danych? Czy nadal powinienem dążyć do znormalizowanej bazy danych?
Na przykład mam konkretny przypadek użycia;
Mam użytkownika z historią wynajmu (tablica adresów). Czy tablica ta powinna być tablicą użytkownika, czy może stanowić osobną kolekcję ze wspólnym kluczem?
Odpowiedzi:
Właściwym podejściem do projektowania baz danych NoSQL jest DDD ( Domain Driven Design ). Dla niektórych osób, które kiedyś projektowały RDBMS, NoSql wygląda jak anty-wzorce Sql i ma większy sens, gdy jest rozważany w zakresie DDD.
W zależności od użycia adresów możesz zdefiniować go jako obiekt wartości w modelu / obiekcie historii wynajmu.
Oto kilka referencji, które mogą oczyścić myśli na temat projektowania za pomocą NoSQL:
źródło
TL; DR
Normalizacja w RDBMS pozwala wykorzystać zalety paradygmatu relacyjnego.
Denormalizacja w NoSQL pozwala wykorzystać mocne strony paradygmatu NoSQL.
Długa odpowiedź
RDBMS są świetne, ponieważ pozwalają modelować unikalne struktury (zmienne lub nie) i ich wzajemne relacje. Oznacza to, że bardzo łatwo jest pracować na poziomie bytu, aktualizować ich właściwości, wstawiać inny, usuwać itp. Ale świetnie nadaje się również do dynamicznego ich agregowania, psa z właścicielem, psa z domami, w których mieszka itp. RDBMS zapewnia narzędzia ułatwiające to wszystko. Przyłączy się do ciebie, poradzi sobie z atomowymi zmianami między bytami itp.
Bazy danych NoSQL są świetne, ponieważ pozwalają modelować częściowo / nieustrukturyzowane agregaty i jednostki dynamiczne. Oznacza to, że bardzo łatwo jest modelować ciągle zmieniające się podmioty, podmioty, które nie mają tych samych atrybutów i hierarchicznych agregatów.
Aby modelować dla NoSql, musisz myśleć w kategoriach hierarchii i agregatów zamiast encji i relacji. Więc nie masz osoby, adresów wynajmu i relacji między nimi. Masz rekordy wynajmu, które agregują dla każdej osoby, jakie adresy wynajmu mieli.
Musisz zapytać, jakie dane będę musiał zmienić razem. Jakie dane logicznie grupują pozostałe dane. W twoim przypadku osoba brzmi jak dobry agregat. Jaki jest logiczny punkt wejścia do reszty danych.
NoSQL, powiedzmy, przechowuj coś, co ma inne rzeczy, które mają swoje. Oddaj mi całą hierarchię rzeczy. Pozwólcie, że zmienię to, co chcę, a teraz zastąpię całą hierarchię rzeczy moim zmienionym. To prawie wszystko, co ci daje. Dlaczego to jest przydatne? Jeśli masz hierarchię rzeczy, z którą zawsze wchodzisz w interakcję jako całość. Lub jeśli musisz masowo skalować.
Wszystko, co daje ci RDBMS, musisz ręcznie wdrożyć w kodzie i schemacie. Musisz dołączyć kod, jeśli kiedykolwiek będziesz potrzebować agregatu agregatów. Musisz przeanalizować, jeśli potrzebujesz tylko części agregatu. Musisz sam sprawdzić niepowtarzalność, jeśli nie chcesz powielać rzeczy. Będziesz musiał wdrożyć własną logikę transakcyjną podczas pracy z agregatami itp.
Tak więc posiadanie jednego dużego stołu ze wszystkim, czego potrzebujesz, jest sposobem na skorzystanie z NoSql. Ponieważ atomowość jest gwarantowana tylko na tym poziomie, a także wydajność. Ważne jest wczesne ustalenie relacji. Na tym polega denormalizacja.
W RDBMS denormalizacja skutecznie paraliżuje twoją DB do NoSQL. Tak więc normalnie chcesz czegoś przeciwnego, to znaczy normalizacji. Jeśli nie, powinieneś zamiast tego używać bazy danych NoSQL. Chyba że potrzebujesz trochę obu.
źródło