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
Il vantaggio 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é puoi eseguire query in modo efficiente all'interno di tale struttura (questo significa che puoi prendere la parte del documento di cui hai bisogno, quindi le dimensioni del documento non dovrebbero preoccuparti molto) non è necessario normalizzare immediatamente dati come lo faresti in SQL. In particolare tutti i dati che non sono utili a parte il suo documento padre 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 mantenere i riferimenti ad esso in altri luoghi.
-
Considerazioni sulle dimensioni 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 sembra piccolo, ma sono anche 30mila tweet o 250 tipiche risposte di Stack Overflow o 20 foto con sfarfallio. D'altra parte, si tratta di molte più informazioni di quelle che si potrebbero voler presentare contemporaneamente su una tipica pagina web. Per prima cosa considera cosa renderà più facili le tue domande. In molti casi la preoccupazione per le dimensioni dei documenti sarà l'ottimizzazione prematura.
-
Strutture dati complesse:
MongoDB può memorizzare strutture di dati nidificate in profondità arbitrarie, ma non può ricercarle in modo efficiente. Se i tuoi dati formano un albero, una foresta o un grafico, devi effettivamente archiviare ogni nodo e i suoi bordi in un documento separato. (Nota che ci sono archivi dati progettati specificamente per questo tipo di dati che dovresti prendere in considerazione)
È stato anche sottolineato che è impossibile restituire un sottoinsieme di elementi in un documento. Se devi scegliere alcuni frammenti 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 atomico, mentre gli aggiornamenti a più documenti non dovrebbero mai essere considerati atomici. Non c'è nemmeno modo di "bloccare" un record sul server (puoi integrarlo nella logica del client usando ad esempio un campo "blocco"). Quando progetti il tuo schema, considera come manterrai i tuoi dati coerenti. In genere, più tieni in un documento, meglio è.
Per quello che stai descrivendo, incorporerei i commenti e assegnerei a ciascun commento un campo ID con un ObjectID. L'ObjectID ha un timestamp incorporato in modo che tu possa usarlo invece di creato in se lo desideri.
