2011-01-06 16 views

Odpowiedz

3

Sposób modelowania wielu do wielu zależy od tego, jakiego rodzaju zapytania chcesz zapytać, w jaki sposób chcesz zaktualizować dane, itp ... Powiedzmy, że mamy foos związane z paskami w wielu wiele mody.

Można modelować foo jako

{ 
    'bars': ['bar1', 'bar2', 'bar3'] 
} 

i modelować bar jak

{ 
    'foos': ['foo_x', 'foo_y', 'foo_z'] 
} 

Albo można modelować wykres lub stosunków między foo i bar w poszczególnych dokumentów siebie

{ 
    from: 'foo1', 
    to: 'bar1' 
} 

{ 
    from: 'foo1', 
    to: 'bar2' 
} 

{ 
    from: 'foo2', 
    to: 'bar3 
} 

{ 
    from 'foo3', 
    to: 'bar3' 
} 

Istnieje wiele innych sposobów. Sposób, w jaki chcesz to zrobić, zależy od pytań, które chcesz zadać, od operacji, które chcesz wspierać, od tego, co chcesz osiągnąć, oraz od indeksowania dostępnego w bazie danych.

2

Zakładając, że mówimy o przypadkach, w których związek jest naprawdę potrzebny, a nie tylko tych, które istnieją tylko dlatego, że SQL obsługuje relacje lepiej niż złożone obiekty, projekt jest podobny do standardowego dla SQL - dwa do wielu relacji.

Kluczową różnicą jest to, że masz pola wielowartościowe, więc zamiast trzeciego dokumentu/tabeli rejestrującego pojedyncze połączenia jako parę identyfikatorów, masz listę identyfikatorów w każdym dokumencie.

Jeśli natkniesz się na przypadki, w których lista jest zbyt długa, prawdopodobnie szukasz czegoś, co lepiej poradziłoby sobie z indeksowaniem wyszukiwania niż relacją.

+0

on mówi o dokumentacji –

+0

nie, to jest "dokument bazy danych". "Baza danych dokumentów" to coś takiego jak http://www.mongodb.org/ –