Możesz zaprojektować schemat, w którym możesz odwoływać się lub osadzać dokumenty. Spójrzmy na pierwszą opcję osadzonych dokumentów. W przypadku powyższej aplikacji możesz przechowywać informacje w dokumencie w następujący sposób:
// db.table1 schema
{
"_id": 3, // table1_id
"is_active": true,
"created": ISODate("2015-04-07T16:00:30.798Z"),
"lang": [
{
"name": "foo",
"surname": "bar",
"address": "xxx"
},
{
"name": "abc",
"surname": "def",
"address": "xyz"
}
]
}
W powyższym przykładowym schemacie zasadniczo osadziłbyś table1_lang informacje w głównej table1 dokument. Ten projekt ma swoje zalety, jedną z nich jest lokalizacja danych. Ponieważ MongoDB przechowuje dane na dysku w sposób ciągły, umieszczenie wszystkich potrzebnych danych w jednym dokumencie zapewnia, że wirujące dyski będą potrzebowały mniej czasu na poszukiwanie określonej lokalizacji na dysku. Jeśli Twoja aplikacja często uzyskuje dostęp do table1 informacje wraz z table1_lang dane, wtedy prawie na pewno będziesz chciał skorzystać z wbudowanej trasy. Inną zaletą osadzonych dokumentów jest niepodzielność i izolacja w zapisie danych. Aby to zilustrować, powiedzmy, że chcesz usunąć dokument, który ma klucz lang "name" o wartości "foo", można to zrobić za pomocą jednej (atomowej) operacji:
db.table.remove({"lang.name": "foo"});
Więcej informacji na temat modelowania danych w MongoDB można znaleźć w dokumentacji Wprowadzenie do modelowania danych , w szczególności Model Relacje jeden-do-wielu z osadzonymi dokumentami
Inną opcją projektowania jest odwoływanie się do dokumentów, w których stosujesz znormalizowany schemat. Na przykład:
// db.table1 schema
{
"_id": 3
"is_active": true
"created": ISODate("2015-04-07T16:00:30.798Z")
}
// db.table1_lang schema
/*
1
*/
{
"_id": 1,
"table1_id": 3,
"name": "foo",
"surname": "bar",
"address": "xxx"
}
/*
2
*/
{
"_id": 2,
"table1_id": 3,
"name": "abc",
"surname": "def",
"address": "xyz"
}
Powyższe podejście daje większą elastyczność w wykonywaniu zapytań. Na przykład, aby pobrać wszystkie potomne table1_lang dokumenty dla głównej jednostki nadrzędnej table1 z id 3 będzie proste, po prostu utwórz zapytanie względem kolekcji table1_lang :
db.table1_lang.find({"table1_id": 3});
Powyższy znormalizowany schemat wykorzystujący podejście odwołania do dokumentu ma również zaletę w przypadku relacji jeden-do-wielu o bardzo nieprzewidywalnej zmienności. Jeśli masz setki lub tysiące table_lang dokumenty na dany table osadzanie ma tak wiele niedogodności, jeśli chodzi o ograniczenia przestrzenne, ponieważ im większy dokument, tym więcej pamięci RAM wykorzystuje, a dokumenty MongoDB mają sztywny limit rozmiaru 16 MB.
Ogólna zasada jest taka, że jeśli wzorzec zapytania aplikacji jest dobrze znany, a dostęp do danych jest zwykle możliwy tylko w jeden sposób, podejście osadzone działa dobrze. Jeśli Twoja aplikacja wysyła zapytania do danych na wiele sposobów lub nie możesz przewidzieć wzorców zapytań o dane, w takim przypadku odpowiedni będzie bardziej znormalizowany model odwoływania się do dokumentów.
Nr ref.:
