Según la información que proporcionó, recomendaría dos enfoques posibles, comenzando desde la misma base:
Recomendaría este enfoque si:
- Tienes una cardinalidad alta tanto de documentos de artículos como de plataformas
-
Desea poder administrar ambas entidades de forma independiente, al mismo tiempo que sincroniza las referencias entre ellas
// 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", ... }
Incluso si este enfoque es bastante flexible, tiene un costo:si necesita datos tanto del artículo como de la plataforma, tendrá que enviar más consultas a su instancia de MongoDB, ya que los datos se dividen en dos colecciones diferentes.
Por ejemplo, al cargar la página de un artículo, teniendo en cuenta que también desea mostrar una lista de platforms , tendría que enviar una consulta a la articles collection y, a continuación, active una búsqueda en la platforms collection para recuperar todas las entidades de la plataforma en las que se publica ese artículo a través de los miembros de la platform s array en el article document .
Sin embargo, si solo tiene un pequeño subconjunto de platform attributes a los que se accede con frecuencia que debe tener disponible al cargar un article document , puede mejorar las platforms matriz en la articles collection para almacenar esos atributos además del _id referencia a los documentos de la plataforma:
// 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"}
],
...
Este enfoque híbrido sería adecuado si los platform data attributes que recupera con frecuencia para mostrar junto con los datos específicos del artículo no cambian con tanta frecuencia.
De lo contrario, deberá sincronizar todas las actualizaciones que se realicen en los platform document attributes en la platforms collection con el subconjunto de atributos que rastrea como parte de la matriz de plataformas para documentos de artículos.
En cuanto a la gestión de listas de artículos para plataformas individuales, no recomendaría almacenar referencias de N a N en ambas colecciones, ya que el mecanismo mencionado anteriormente ya permite extraer listas de artículos consultando la articles collection. usando una consulta de búsqueda con el _id valor del platform document :
Approach #1
db.articles.find({"platforms": "platform_1"});
Approach #2:
db.articles.find({"platforms.platform_id": "platform_1"});
Habiendo presentado dos enfoques diferentes, lo que recomendaría ahora es que analice los patrones de consulta y los umbrales de rendimiento de su aplicación y tome una decisión calculada en función de los escenarios que encuentre.
