Non sempre, la normalizzazione fino alla morte infligge colpi di prestazioni, ma è vero che personalmente non applico a MongoDB la stessa normalizzazione di SQL.
Se sei a conoscenza dei moduli normalizzati ( http://en.wikipedia.org/wiki/Database_normalization ) Mi piace pensare che MongoDB vada a 1NF e poi torni a denormalizzarsi di nuovo.
Oh sì lo facciamo. L'aggiornamento è una seccatura se i dati vengono duplicati in modo errato.
Lascia che ti faccia un esempio:category e product sarebbero due entità separate, non si può negarlo. Queste due entità sono normalizzate (i dati ripetuti di product è stato separato da category ). Un altro modo di pensare è:Esisteranno tutti i prodotti in una sola categoria?
Quindi sulle entità di primo livello, come puoi vedere, le stesse regole si applicano relativamente con 1NF facilmente applicabile a MongoDB.
Per quanto riguarda la duplicazione, ovviamente, non vorresti memorizzare ogni prodotto separatamente all'interno di ciascuna categoria (ho risposto no alla domanda sopra), quindi vorresti naturalmente separare categorie e prodotti.
Normalmente avresti una relazione molti-a-molti qui con una tabella normalizzata centrale. È qui che può entrare in gioco la denormalizzazione. Puoi dire che una categoria avrà un elenco di prodotti che sono unici per quella categoria in quanto tale potresti denormalizzare la tabella relazionale molti-a-molti nella riga della categoria come elenco (o viceversa nella riga del prodotto). Ciò non genererà duplicati poiché quell'elenco è unico per quella categoria (più che probabile). Questo ovviamente significa che la categoria oi prodotti conterrebbero un elenco _id s della riga correlata al posto dell'oggetto stesso.
Ci sono momenti in cui la duplicazione è necessaria, principalmente per l'ottimizzazione o soluzioni alternative per non avere JOIN; questa regola si applica anche a SQL se hai mai realizzato un sito abbastanza grande.
Gli scenari di utilizzo tipici della duplicazione sono i campi di aggregazione delle statistiche come le condivisioni e i commenti di un post di Facebook e forse anche gli ultimi 5 commenti di quel post verrebbero duplicati nella riga del post.
Quindi non si tratta di ignorare la progettazione dello schema, ma piuttosto di ottimizzarlo per le caratteristiche di MongoDB. Normalmente, se lo fai, scoprirai che, naturalmente, progetti un buon schema.
Come riferimento aggiuntivo puoi fare riferimento qui:http://docs.mongodb.org/ modellazione manuale/core/dati
