Relazioni MongoDB: incorporare o fare riferimento?

Sono nuovo di MongoDB, proveniente da un background di database relazionale. Voglio progettare una struttura di domande con alcuni commenti, ma non so quale relazione usare per i commenti: embedo reference?

Una domanda con alcuni commenti, come StackOverflow , avrebbe una struttura come questa:

Question
    title = 'aaa'
    content = bbb'
    comments = ???

All'inizio, voglio usare i commenti incorporati (penso che embedsia consigliato in MongoDB), in questo modo:

Question
    title = 'aaa'
    content = 'bbb'
    comments = [ { content = 'xxx', createdAt = 'yyy'}, 
                 { content = 'xxx', createdAt = 'yyy'}, 
                 { content = 'xxx', createdAt = 'yyy'} ]

È chiaro, ma sono preoccupato per questo caso: se voglio modificare un commento specificato, come ottengo il suo contenuto e la sua domanda? Non c'è modo _iddi farmi trovare uno, né question_refdi farmi trovare la sua domanda. (Sono così alle prime armi, che non so se c'è modo di farlo senza _ide question_ref.)

Devo usare ref non embed? Quindi devo creare una nuova raccolta per i commenti?

Questa è più un'arte che una scienza. La documentazione Mongo sugli schemi è un buon riferimento, ma qui ci sono alcune cose da considerare:

• Metti il ​​più possibile

  La gioia di un database di documenti è che elimina molti join. Il tuo primo istinto dovrebbe essere quello di inserire il più possibile in un unico documento. Poiché i documenti MongoDB hanno una struttura e poiché è possibile eseguire query in modo efficiente all'interno di tale struttura (ciò significa che è possibile prendere la parte del documento di cui hai bisogno, quindi le dimensioni del documento non dovrebbero preoccuparti molto) non è necessario immediatamente normalizzare dati come lo faresti in SQL. In particolare, tutti i dati non utili a parte il documento principale dovrebbero far parte dello stesso documento.

• Separare i dati a cui è possibile fare riferimento da più posizioni nella propria raccolta.

  Questo non è tanto un problema di "spazio di archiviazione" quanto un problema di "coerenza dei dati". Se molti record faranno riferimento agli stessi dati, è più efficiente e meno soggetto a errori aggiornare un singolo record e conservarne i riferimenti in altri luoghi.

• Considerazioni sulla dimensione del documento

  MongoDB impone un limite di dimensione di 4 MB (16 MB con 1,8) su un singolo documento. In un mondo di GB di dati questo sembra piccolo, ma sono anche 30 mila tweet o 250 risposte tipiche di Stack Overflow o 20 foto sfarfallio. D'altra parte, si tratta di molte più informazioni di quelle che si potrebbero desiderare di presentare contemporaneamente in una tipica pagina Web. Innanzitutto considera cosa renderà le tue domande più facili. In molti casi la preoccupazione per le dimensioni del documento sarà l'ottimizzazione prematura.

• Strutture dati complesse:

  MongoDB può archiviare strutture di dati annidate in profondità arbitrarie, ma non può cercarle in modo efficiente. Se i tuoi dati formano un albero, una foresta o un grafico, devi effettivamente memorizzare ciascun nodo e i suoi bordi in un documento separato. (Si noti che ci sono archivi di dati appositamente progettati per questo tipo di dati che si dovrebbero considerare anche)

  È stato anche sottolineato che è impossibile restituire un sottoinsieme di elementi in un documento. Se devi selezionare alcuni bit di ciascun documento, sarà più facile separarli.

• Coerenza dei dati

  MongoDB fa un compromesso tra efficienza e coerenza. La regola è che le modifiche a un singolo documento sono sempre atomiche, mentre gli aggiornamenti a più documenti non dovrebbero mai essere considerati atomici. Non è inoltre possibile "bloccare" un record sul server (è possibile inserirlo nella logica del client utilizzando ad esempio un campo "blocco"). Quando progetti lo schema, considera come manterrai i tuoi dati coerenti. Generalmente, più ne conservi in ​​un documento, meglio è.

Per quello che stai descrivendo, incorporerei i commenti e darei ad ogni commento un campo ID con un ObjectID. L'ObjectID ha un timestamp incorporato in esso in modo da poterlo utilizzare invece di crearlo se lo desideri.

In generale, l'incorporamento è positivo se si hanno relazioni uno-a-uno o uno-a-molti tra entità e il riferimento è buono se si hanno relazioni a molti a molti.

Se voglio modificare un commento specificato, come ottenerne il contenuto e la domanda?

È possibile eseguire una query per documento secondario: db.question.find({'comments.content' : 'xxx'}) .

Ciò restituirà l'intero documento della domanda. Per modificare il commento specificato, è quindi necessario trovare il commento sul client, apportare la modifica e salvarlo nuovamente nel DB.

In generale, se il tuo documento contiene una matrice di oggetti, scoprirai che questi oggetti secondari dovranno essere modificati sul lato client.

Bene, sono un po 'in ritardo ma vorrei comunque condividere il mio modo di creare uno schema.

Ho schemi per tutto ciò che può essere descritto da una parola, come faresti con il classico OOP.

PER ESEMPIO

• Commento
• account
• Utente
• Post sul blog
• ...

Ogni schema può essere salvato come documento o documento secondario, quindi lo dichiaro per ogni schema.

Documento:

• Può essere usato come riferimento. (Ad esempio, l'utente ha fatto un commento -> commento ha un riferimento "creato da" all'utente)
• È un "Root" nella tua applicazione. (Ad esempio il blogpost -> c'è una pagina sul blogpost)

Documento secondario:

• Può essere usato solo una volta / non è mai un riferimento. (Ad esempio, il commento viene salvato nel post del blog)
• Non è mai un "Root" nella tua applicazione. (Il commento appare solo nella pagina del post del blog ma la pagina riguarda ancora il post del blog)

Mi sono imbattuto in questa piccola presentazione mentre cercavo questa domanda da solo. Sono rimasto sorpreso dal modo in cui è stato preparato, sia le informazioni che la presentazione.

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

Ha riassunto:

Come regola generale, se hai molti [documenti secondari] o se sono grandi, una raccolta separata potrebbe essere la migliore.

Documenti più piccoli e / o meno tendono ad essere una scelta naturale per l'incorporamento.

So che questo è piuttosto vecchio ma se stai cercando la risposta alla domanda del PO su come restituire solo il commento specificato, puoi usare l' operatore $ (query) in questo modo:

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

Sì, possiamo usare il riferimento nel documento. Per popolare un altro documento proprio come sql i join. A mongo db non hanno join per mappare uno a molti documenti di relazione. Invece possiamo usare populate per soddisfare il nostro scenario.

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' }]
});

La popolazione è il processo di sostituzione automatica dei percorsi specificati nel documento con documenti di altre raccolte. È possibile popolare un singolo documento, più documenti, un oggetto semplice, più oggetti semplici o tutti gli oggetti restituiti da una query. Diamo un'occhiata ad alcuni esempi.

Meglio che tu possa ottenere maggiori informazioni, visitare: http://mongoosejs.com/docs/populate.html

In realtà, sono abbastanza curioso del perché nessuno abbia parlato delle specifiche UML. Una regola empirica è che se si dispone di un'aggregazione, è necessario utilizzare i riferimenti. Ma se è una composizione, l'accoppiamento è più forte e dovresti usare documenti incorporati.

E capirai rapidamente perché è logico. Se un oggetto può esistere indipendentemente dal genitore, allora vorrai accedervi anche se il genitore non esiste. Dato che non puoi semplicemente incorporarlo in un genitore inesistente, devi renderlo attivo nella sua struttura di dati. E se esiste un genitore, basta collegarli insieme aggiungendo un riferimento all'oggetto nel genitore.

Non sai davvero qual è la differenza tra le due relazioni? Ecco un link che li spiega: Aggregazione vs Composizione in UML

Ho creato questo quiz come riferimento per sapere se dovresti usare l'uno o l'altro

http://indie-rok.github.io/embedded-vs-reference-mongo-db

Se voglio modificare un commento specificato, come ottengo il suo contenuto e la sua domanda?

Se avessi tenuto traccia del numero di commenti e dell'indice del commento che desideri modificare, puoi utilizzare l'operatore punto ( esempio SO ).

Potresti fare f.ex.

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

(come un altro modo per modificare i commenti all'interno della domanda)