L'esempio che fai, in comune con la maggior parte degli esempi del mondo reale di relazioni molti-a-molti, è in realtà un esempio di pochi-pochi relazione. Potresti avere molti ristoranti e molti commensali ma, rispetto all'intero set, un dato ristorante ha servito solo un piccolo sottogruppo di commensali e la maggior parte dei singoli commensali avrà visitato solo un piccolo sottoinsieme dei ristoranti. Sembra una rete scarsamente collegata in cui il rapporto di densità dei collegamenti è notevolmente inferiore a uno.
Tuttavia, hai chiesto molti a molti, quindi che ne dici di usare una rete neurale come esempio? Le reti neurali spesso formano reti dense e quindi rappresentano una vera rete molti-a-molti. In tal caso la risposta è semplice:non utilizzare mongoDB. Utilizza strutture personalizzate e strategie di serializzazione su misura per i tuoi requisiti specifici. Dopotutto, le vere relazioni molti-a-molti sono quasi sempre valori anomali e quindi giustificano un trattamento specifico.
Detto questo, modellando il più consueto pochi a pochi la relazione in mongoDB può essere raggiunta senza sacrificare la ricca struttura del documento e il modo in cui lo ottieni dipende dai tuoi modelli di accesso.
Quindi, con l'esempio della rete ristorante / tavola calda, se in genere si esegue una query su un ristorante sui suoi commensali, si creerà una matrice di diner_id tenuti con ciascun ristorante. L'altro modo significherebbe una serie di restaurant_id tenuti con ogni commensale. Entrambi per la capacità di query bidirezionale.
È necessario prestare attenzione perché non esiste un vincolo di chiave esterna in mongoDB e quindi mantenere l'integrità referenziale dei dati è una tua responsabilità.
Se le prestazioni sono più importanti per te, potresti voler incorporare i dati in ogni documento piuttosto che farvi riferimento con un ID. Questa è l'opzione con prestazioni più elevate per la lettura (non tanto per la scrittura) poiché tutti i dati possono essere estratti dal disco in un colpo solo. Significa che dovrai fare più lavoro quando aggiorni i valori dei dati per garantire l'integrità dei tuoi dati, ma spesso questo non è così spaventoso come sembra a prima vista. Quante volte i commensali cambiano davvero i loro nomi? E a seconda delle dimensioni del documento, potresti non voler necessariamente incorporare l'intero documento, spesso un sottoinsieme di dati più un ID per puntare al record completo.
In breve, la progettazione dello schema mongoDB dovrebbe essere guidata dai requisiti dell'applicazione. Schemi diversi per applicazioni diverse rispetto a un DB relazionale monolitico per dominarli tutti. Qual è la realtà dei dati? In che modo l'applicazione utilizza effettivamente questi dati? Quanto sono grandi gli oggetti del documento archiviati? Rispondi a queste domande e il tuo schema sarà praticamente progettato da solo.
