Początkujący MongoDB - czy znormalizować, czy nie?

Question

OK, spróbuję zrobić to tak prosto, jak tylko mogę.
comming z MySQL i myślenia w tabelach, użyjmy następujący przykład:
Załóżmy, że mamy stronę internetową na rynku nieruchomości i jesteśmy wyświetlania listy domów
normalnie, chciałbym skorzystać z następujących tabel:
* domy - nieruchomości pod ręką
* właściciele - właściciel domu - jeden do wielu relacji z domami
* agencje - agencja pośrednictwa w obrocie nieruchomościami - wiele do wielu relacji z domami
* obrazy - relacja wiele do jednego z domami
* opinie - wiele relacji jeden do jednego z domami

Rozumiem, że MongoDB zapewnia elastyczność w projektowaniu aplikacji internetowej w różnych kolekcjach z unikalnym identyfikatorem bardzo podobnym do relacyjnej bazy danych (znormalizowanej), a do szybkiego wybierania można zagnieździć się w kolekcji, powiązanych obiektach i danych (un-znormalizowany).
Powrót do naszej listy domów nieruchomości, zapytanie użyte do zapełnienia jest dość kosztowne w normalnym relacyjnym DB, dla każdego domu trzeba zapytać o jego obrazy, recenzje, agencje właściciela &, każda jednostka znajduje się w innej tabeli z jego pola, prawdopodobnie użyjesz złączeń i będziesz mieć wiele zapytań w jednym - Drogie!
Wprowadź MongoDB - tam, gdzie nie potrzebujesz złączeń, i możesz przechowywać wszystkie powiązane dane z domu w domu w kolekcji domów, wybór nigdy nie był szybszy, to db niebo!
Och - ale co się stanie, gdy trzeba będzie dodać/zaktualizować/usunąć powiązane recenzje/agencje/właściciela/obrazy?
jest to dla mnie tajemnicą, a jeśli muszę zgadywać, każda powiązana kolekcja istnieje na swojej własnej kolekcji na podstawie danych w tabeli domów, a gdy jeden z tych fragmentów powiązanych danych zostanie dodany/zaktualizowany/usunięty będziesz musiał zaktualizować go na swojej własnej kolekcji, a także na kolekcji domów.
Po tej aktualizacji - czy muszę również wysyłać zapytania do innych kolekcji, aby upewnić się, że aktualizuję rekord domu ze wszystkimi zaktualizowanymi powiązanymi danymi?
Jestem naprawdę zgadywania tutaj ... i docenić swoją opinię
dziękczynienie
uchylone

Answer 1

Spróbuj podejście:

ustalić, która jednostka (lub jednostki) to bohater (s)

Z "bohaterem" mam na myśli podmiot (y), na którym koncentruje się baza danych. Weźmy twój przykład. Bohaterem przykładu z nieruchomości jest dom *.

wypracować właścicielu

przejść przez inne podmioty, takie jak właściciel, agencji, zdjęć i opinii i zadać sobie pytanie, czy to ma sens, aby umieścić swoje dane wraz z domem. Czy miałbyś kaskadowe usuwanie któregoś z kluczy obcych w relacyjnej bazie danych? Jeśli tak, to oznacza własność.

Work, czy rzeczywiście jest to ważne, że dane są de-znormalizowana

Będziesz mieć agencję (i prawdopodobnie właściciela) Szczegóły rozłożone w wielu domach. Czy to ma znaczenie?

Twój dom kolekcja prawdopodobnie będzie wyglądać następująco:

house: { 
owner, 
agency, 
images[], // recommend references to GridFS here 
reviews[] // you probably won't get too many of these for a single house 
} 

* Właściwie, to chyba reklama domu (ponieważ domy są zazwyczaj ogłaszane na stronie internetowej od nieruchomości i to jest chyba to, co jesteś naprawdę interesujący jest), więc pomyśl tylko, że

Answer 2

Sarah Mei napisała artykuł informacyjny na temat rodzajów problemów, które mogą powstać w związku z integralnością danych w nosql dbs. Wybór między zduplikowanymi danymi lub używanie identyfikatorów, połączeń opartych na kodach i wyzwaniami związanymi z zachowaniem integralności danych. Podejrzewa ona, że ​​wszelkie nosql db z połączeniami opartymi na kodzie w pewnym momencie straci integralność danych. Imho komentarze do artykułów są równie cenne jak sam artykuł w zrozumieniu tych kwestii i możliwych rozwiązań.

Link: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/comment-page-1/

Answer 3

Chciałbym dać odświeżające normalizacji z punktu widzenia MongoDB „s -

Jakie są cele normalizacji?

• Zwalnia bazy danych przed modyfikacją anomalie - Na MongoDB, wygląda na to, że osadzanie danych najczęściej przyczyną tego. W rzeczywistości powinniśmy starać się unikać umieszczania danych w dokumentach w MongoDB, które mogą powodować te anomalie. Czasami może zajść konieczność duplikowania danych w dokumentach ze względu na wydajność. Jednak nie jest to podejście domyślne. Domyślnie jest to unikanie.
• powinny minimalizować re-design przy przedłużaniu - MongoDB jest wystarczająco elastyczny, ponieważ pozwala na dodawanie kluczy bez konieczności ponownego projektowania wszystkie dokumenty
• unikać stronniczości wobec żadnego konkretnego wzoru dostępu - to jest coś, jesteśmy nie martwiąc się o opisywanie schematu w MongoDB. Jedną z idei stojących za MongoDB jest dostrojenie bazy danych do aplikacji, które próbujemy napisać, oraz problem, który próbujemy rozwiązać.