Sulla base delle informazioni che hai fornito, consiglierei due possibili approcci, partendo dalla stessa base:
Consiglierei questo approccio se:
- Hai un'elevata cardinalità di entrambi i documenti degli articoli, nonché delle piattaforme
-
Vuoi essere in grado di gestire entrambe le entità in modo indipendente, sincronizzando anche i riferimenti tra di loro
// articles collection schema { "_id": ..., "title": "I am an article", ... "platforms": [ "platform_1", "platform_2", "platform_3" ], ... } // platforms collection schema { "_id": "platform_1", "name": "Platform 1", "url": "http://right/here", ... }, { "_id": "platform_2", "name": "Platform 2", "url": "http://right/here", ... }, { "_id": "platform_3", "name": "Platform 3", "url": "http://right/here", ... }
Anche se questo approccio è abbastanza flessibile, ha un costo:se hai bisogno sia dei dati dell'articolo che della piattaforma, dovrai eseguire più query sulla tua istanza MongoDB, poiché i dati sono divisi in due raccolte diverse.
Ad esempio, quando si carica la pagina di un articolo, considerando che si desidera visualizzare anche un elenco di platforms , dovresti inviare una query alla articles collection , quindi attiva anche una ricerca nella platforms collection per recuperare tutte le entità della piattaforma in cui è pubblicato quell'articolo tramite i membri della platform s array nel article document .
Tuttavia, se hai solo un piccolo sottoinsieme di platform attributes a cui si accede frequentemente che devi avere a disposizione quando carichi un article document , potresti migliorare le platforms array nella articles collection per memorizzare quegli attributi oltre a _id riferimento ai documenti della piattaforma:
// enhanced articles collection schema
{
"_id": ...,
"title": "I am an article",
...
"platforms": [
{platform_id: "platform_1", name: "Platform 1"},
{platform_id: "platform_2", name: "Platform 2"},
{platform_id: "platform_3", name: "Platform 3"}
],
...
}
Questo approccio ibrido sarebbe adatto se gli platform data attributes che recuperi di frequente per visualizzare insieme ai dati specifici dell'articolo non cambiano così spesso.
In caso contrario, dovrai sincronizzare tutti gli aggiornamenti apportati agli platform document attributes nella platforms collection con il sottoinsieme di attributi che tieni traccia come parte dell'array piattaforme per i documenti degli articoli.
Per quanto riguarda la gestione delle liste di articoli per le singole piattaforme, sconsiglio di memorizzare i riferimenti N-to-N in entrambe le raccolte, in quanto il suddetto meccanismo consente già di estrarre le liste di articoli interrogando la articles collection utilizzando una query di ricerca con _id valore del platform document :
Approach #1
db.articles.find({"platforms": "platform_1"});
Approach #2:
db.articles.find({"platforms.platform_id": "platform_1"});
Avendo presentato due diversi approcci, ciò che consiglierei ora è di analizzare i modelli di query e le soglie di prestazioni della tua applicazione e prendere una decisione calcolata in base agli scenari che incontri.
