Progettazione di schemi di database Mongodb con dati condivisi

La tua sfida deriva dal fatto che Prop_Info deve essere recuperato da entrambe le query. Questo rende difficile capire in quale collezione Mongo dovrebbe vivere.

In MongoDB, crei lo schema del tuo documento con l'obiettivo ideale che un singolo documento abbia tutte le informazioni di cui hai bisogno in base ai tuoi modelli di query. Nel caso in cui devi avere gli stessi dati D (come Prop_Info nel tuo caso) restituito da due query separate su due raccolte separate A e B , devi scegliere tra le seguenti tre strategie:

1. Duplica D nei documenti di entrambi A e B e imporre la coerenza con il codice. Questa è in genere la scelta progettuale di sistemi ad alte prestazioni che vogliono eliminare la necessità di una seconda query anche se ciò comporta il costo di un'ulteriore complessità del codice sul lato di inserimento/aggiornamento e con alcuni potenziali problemi di coerenza poiché Mongo non è ACID.

2. Metti D in A e memorizza un riferimento (DBRef o qualche altra combinazione di campi identificativi) in B in modo da poterlo ottenere con una seconda query. Questa è in genere la scelta di progettazione quando il numero di query su A supera il numero di query a B . Mantiene D locale alla raccolta più frequentemente richiesta. In questo modello di progettazione dello schema devi solo eseguire una seconda query quando esegui una query su B .

3. Metti D in una nuova collezione C ed esegui una seconda query da entrambi A e B . Questa è in genere la scelta progettuale di fronte a requisiti futuri molto incerti in cui non è chiaro quali sarebbero i compromessi se si sceglie (1) o (2) sopra. È lo schema più "relazionale" e quello che ti costringerà a fare una seconda query quando esegui una query su entrambi A e B .

La strategia che scegli dipende dal tuo dominio, dai modelli di query, dal supporto che ottieni dal tuo framework di mappatura relazionale a oggetti (ORM) (se ne usi uno) e, ultimo ma non meno importante, dalle tue preferenze.

Nelle situazioni che ho incontrato, non ho mai scelto (3). Ho usato (1) in situazioni ad alte prestazioni (sistemi analitici). Ho usato (2) ovunque poiché i modelli di accesso alle query hanno reso ovvio dove dovrebbero risiedere i dati "condivisi".

Una volta scelta la strategia, se hai ancora bisogno di assistenza, pubblica un'altra domanda SO che si concentri specificamente sul problema di progettazione dello schema data la strategia scelta.

Tre consigli finali:

1. Se i dati condivisi D ha una molteplicità di relazioni maggiore di 1 usa un array. È possibile indicizzare interi array e interrogare con precisione all'interno degli array utilizzando $elemMatch .

2. Per aggiornare D nella strategia (1) o (2) utilizzare il modificatore atomico operazioni , molti dei quali sono progettati per funzionare su array.

3. Questa domanda SO copre il modello di query a due DBRef nella risposta di @Stennie. (@Stennie funziona per 10gen, i marcatori di MongoDB.)

Buona fortuna!