Relacje MongoDB: osadzenie czy odniesienie?

Ogólnie rzecz biorąc, embed jest dobry, jeśli masz relacje jeden-do-jednego lub jeden-do-wielu między podmiotami, a odniesienie jest dobre, jeśli masz relacje wiele-do-wielu.

Jeśli chcę edytować podany komentarz, jak uzyskać jego treść i pytanie?

Możesz odpytywać za pomocą pod-dokumentu: db.question.find({'comments.content' : 'xxx'}).

Zwróci to cały dokument z pytaniem. Aby edytować podany komentarz, musisz znaleźć komentarz na kliencie, dokonać edycji i zapisać go z powrotem do DB.

Ogólnie rzecz biorąc, jeśli dokument zawiera tablicę obiektów, okaże się, że te podrzędne obiekty będą musiały zostać zmodyfikowane po stronie klienta.

Cóż, jestem trochę spóźniony, ale nadal chciałbym podzielić się moim sposobem tworzenia schematu.

Mam Schematy wszystkiego, co można opisać słowem, tak jak byś to zrobił w klasycznym OOP.

E. G.

• Skomentuj
• konto
• Użytkownik
• Blogpost
• ...

Każdy schemat można zapisać jako dokument lub Subdokument, więc deklaruję to dla każdego schematu.

Dokument:

• może być używany jako odniesienie. (Np. użytkownik napisał komentarz - > komentarz ma odniesienie "made by" do użytkownika)
• jest "Root" w Twojej aplikacji. (Np. blogpost - > jest strona o blogpost)

Subdocument:

• może być użyty tylko raz / nigdy nie jest odniesieniem. (Np. komentarz jest zapisywany na blogu)
• nigdy nie jest "Root" w Twojej aplikacji. (Komentarz po prostu pojawia się na stronie blogpost, ale strona jest nadal o blogpost)

Natknąłem się na tę małą prezentację, badając to pytanie na własną rękę. Byłem zaskoczony, jak dobrze został on rozplanowany, zarówno informacje, jak i prezentacja.

Http://openmymind.net/Multiple-Collections-Versus-Embedded-Documents

Podsumowano:

Ogólnie rzecz biorąc, jeśli masz dużo [dokumentów potomnych] lub jeśli są one duże, najlepiej może być oddzielny zbiór.

Mniejsze i / lub mniej dokumentów wydają się być naturalnym dopasowaniem do / align = "left" /

Wiem, że jest to dość stare, ale jeśli szukasz odpowiedzi na pytanie OP, Jak zwrócić tylko podany komentarz, możesz użyć operatora $ (query) w następujący sposób:

db.question.update({'comments.content': 'xxx'}, {'comments.$': true})

Tak, możemy użyć referencji w document.To wypełnić inny dokument tak jak sql i joins.In Mongo db oni nie mają łączy do mapowania jeden do wielu dokumentów relacji.Zamiast tego możemy użyć wypełnić aby spełnić nasz scenariusz..

var mongoose = require('mongoose')
  , Schema = mongoose.Schema

var personSchema = Schema({
  _id     : Number,
  name    : String,
  age     : Number,
  stories : [{ type: Schema.Types.ObjectId, ref: 'Story' }]
});

var storySchema = Schema({
  _creator : { type: Number, ref: 'Person' },
  title    : String,
  fans     : [{ type: Number, ref: 'Person' }]
});

Populacja to proces automatycznego zastępowania określonych ścieżek w dokumencie dokumentami z innych kolekcji. Możemy wypełnić pojedynczy dokument, wiele dokumentów, zwykły obiekt, wiele zwykłych obiektów, lub wszystkie obiekty zwrócone z zapytania. Spójrzmy na kilka przykładów.

Lepiej możesz uzyskać więcej informacji odwiedź: http://mongoosejs.com/docs/populate.html

Właściwie to jestem dość ciekawy, dlaczego nikt nie mówił o specyfikacji UML. Zasadą jest, że jeśli masz agregację, powinieneś użyć referencji. Ale jeśli jest to kompozycja, połączenie jest silniejsze i powinieneś użyć osadzonych dokumentów.

I szybko zrozumiesz, dlaczego jest to logiczne. Jeśli obiekt może istnieć niezależnie od rodzica, wtedy będziesz chciał uzyskać do niego dostęp, nawet jeśli rodzic nie istnieje. Ponieważ po prostu nie można osadzić go w nieistniejącym rodzicu, trzeba go wprowadzić do życia w jego własnej strukturze danych. A jeśli rodzic istnieje, po prostu połącz je ze sobą, dodając ref obiektu w rodzicu.

Naprawdę nie wiesz jaka jest różnica między tymi dwoma związkami ? Oto link wyjaśniający je: agregacja a skład w UML

Jeśli chcę edytować podany komentarz, jak uzyskać jego treść i pytanie?

Jeśli śledziłeś liczbę komentarzy i indeks komentarza, który chcesz zmienić, możesz użyć operatora kropki (przykład ).

db.questions.update(
    {
        "title": "aaa"       
    }, 
    { 
        "comments.0.contents": "new text"
    }
)

(jako inny sposób edycji komentarzy wewnątrz pytania)

MongoDB daje swobodę bycia bez schematu i ta funkcja może powodować ból w dłuższej perspektywie, jeśli nie jest dobrze przemyślana lub zaplanowana,

Dostępne są 2 opcje: Embed lub Reference. Nie będę przerabiał definicji, ponieważ powyższe odpowiedzi dobrze je zdefiniowały.

Podczas osadzania powinieneś odpowiedzieć na jedno pytanie, Czy twój osadzony dokument będzie rosnąć, jeśli tak, to ile (pamiętaj, że jest limit 16 MB na dokument) więc jeśli masz coś w rodzaju komentarza do posta, co to jest limit liczby komentarzy, jeśli ten post stanie się wirusowy i ludzie zaczną dodawać komentarze. W takich przypadkach Referencja może być lepszym rozwiązaniem (ale nawet Referencja może rosnąć i osiągnąć limit 16 MB).

Więc jak to zrównoważyć, odpowiedź jest kombinacją różnych wzorców, sprawdź te linki i stwórz swój własny mix i dopasuj w oparciu o swoje użycie case.

Https://www.mongodb.com/blog/post/building-with-patterns-a-summary

Https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-1