Docs Menu
Docs Home
/ /
Relaciones de documentos

Modelar relaciones uno a uno con documentos incrustados

Esta página describe un modelo de datos que utiliza Documentos incrustados para describir una relación biunívoca entre datos conectados. Incrustar datos conectados en un solo documento puede reducir el número de operaciones de lectura necesarias para obtenerlos. En general, debe estructurar su esquema de modo que su aplicación reciba toda la información necesaria en una sola operación de lectura.

Considere el siguiente ejemplo que mapea las relaciones entre usuarios y direcciones. El ejemplo ilustra la ventaja de incrustar sobre referenciar si necesita ver una entidad de datos en el contexto de la otra. En esta relación uno a uno entre patron y address datos, el address pertenece al patron.

En el modelo de datos normalizado, el documento address contiene una referencia al documento patron.

// patron document
{
_id: "joe",
name: "Joe Bookreader"
}
// address document
{
patron_id: "joe", // reference to patron document
street: "123 Fake Street",
city: "Faketon",
state: "MA",
zip: "12345"
}

Si los datos address se recuperan frecuentemente con la información name, entonces, al referenciar, su aplicación necesita ejecutar múltiples consultas para resolver la referencia. El mejor modelo de datos sería incrustar los datos address en los datos patron, como se muestra en el siguiente documento:

{
_id: "joe",
name: "Joe Bookreader",
address: {
street: "123 Fake Street",
city: "Faketon",
state: "MA",
zip: "12345"
}
}

Con el modelo de datos embebido, tu aplicación puede recuperar la información completa del cliente con una sola query.

Un problema potencial con el patrón de documento incrustado es que puede generar documentos extensos que contienen campos innecesarios para la aplicación. Estos datos innecesarios pueden sobrecargar el servidor y ralentizar las operaciones de lectura. En su lugar, puede usar el patrón de subconjunto para recuperar el subconjunto de datos al que se accede con mayor frecuencia en una sola llamada a la base de datos.

Considere una aplicación que muestra información sobre películas. La base de datos contiene una colección movie con el siguiente esquema:

{
"_id": 1,
"title": "The Arrival of a Train",
"year": 1896,
"runtime": 1,
"released": ISODate("01-25-1896"),
"poster": "http://ia.media-imdb.com/images/M/MV5BMjEyNDk5MDYzOV5BMl5BanBnXkFtZTgwNjIxMTEwMzE@._V1_SX300.jpg",
"plot": "A group of people are standing in a straight line along the platform of a railway station, waiting for a train, which is seen coming at some distance. When the train stops at the platform, ...",
"fullplot": "A group of people are standing in a straight line along the platform of a railway station, waiting for a train, which is seen coming at some distance. When the train stops at the platform, the line dissolves. The doors of the railway-cars open, and people on the platform help passengers to get off.",
"lastupdated": ISODate("2015-08-15T10:06:53"),
"type": "movie",
"directors": [ "Auguste Lumière", "Louis Lumière" ],
"imdb": {
"rating": 7.3,
"votes": 5043,
"id": 12
},
"countries": [ "France" ],
"genres": [ "Documentary", "Short" ],
"tomatoes": {
"viewer": {
"rating": 3.7,
"numReviews": 59
},
"lastUpdated": ISODate("2020-01-09T00:02:53")
}
}

Actualmente, la colección movie contiene varios campos que la aplicación no necesita para mostrar una descripción general simple de una película, como fullplot y la información de clasificación. En lugar de almacenar todos los datos de la película en una sola colección, puede dividirla en dos:

  • La colección movie contiene información básica sobre una película. Estos son los datos que la aplicación carga por defecto:

    // movie collection
    {
    "_id": 1,
    "title": "The Arrival of a Train",
    "year": 1896,
    "runtime": 1,
    "released": ISODate("1896-01-25"),
    "type": "movie",
    "directors": [ "Auguste Lumière", "Louis Lumière" ],
    "countries": [ "France" ],
    "genres": [ "Documentary", "Short" ],
    }
  • La colección movie_details contiene datos adicionales a los que se accede con menos frecuencia para cada película:

    // movie_details collection
    {
    "_id": 156,
    "movie_id": 1, // reference to the movie collection
    "poster": "http://ia.media-imdb.com/images/M/MV5BMjEyNDk5MDYzOV5BMl5BanBnXkFtZTgwNjIxMTEwMzE@._V1_SX300.jpg",
    "plot": "A group of people are standing in a straight line along the platform of a railway station, waiting for a train, which is seen coming at some distance. When the train stops at the platform, ...",
    "fullplot": "A group of people are standing in a straight line along the platform of a railway station, waiting for a train, which is seen coming at some distance. When the train stops at the platform, the line dissolves. The doors of the railway-cars open, and people on the platform help passengers to get off.",
    "lastupdated": ISODate("2015-08-15T10:06:53"),
    "imdb": {
    "rating": 7.3,
    "votes": 5043,
    "id": 12
    },
    "tomatoes": {
    "viewer": {
    "rating": 3.7,
    "numReviews": 59
    },
    "lastUpdated": ISODate("2020-01-29T00:02:53")
    }
    }

Este método mejora el rendimiento de lectura, ya que requiere que la aplicación lea menos datos para satisfacer su solicitud más frecuente. La aplicación puede realizar una llamada adicional a la base de datos para recuperar los datos a los que se accede con menos frecuencia si es necesario.

Tip

Al considerar dónde dividir sus datos, la parte de los datos a la que se accede con más frecuencia debe ir en la colección que la aplicación carga primero.

Tip

Para aprender a usar el patrón de subconjunto para modelar relaciones uno-a-muchos entre colecciones, consulta Modelar relaciones uno-a-muchos con documentos incrustados.

El uso de documentos más pequeños que contienen datos de acceso más frecuente reduce el tamaño total del conjunto de trabajo. Estos documentos más pequeños mejoran el rendimiento de lectura y liberan más memoria para la aplicación.

Sin embargo, es importante comprender su aplicación y cómo carga los datos. Si divide los datos en varias colecciones de forma incorrecta, su aplicación a menudo necesitará realizar múltiples viajes a la base de datos y depender de operaciones JOIN para recuperar todos los datos que necesita.

Además, dividir los datos en muchas colecciones pequeñas puede aumentar el mantenimiento necesario de la base de datos, ya que puede resultar difícil rastrear qué datos están almacenados en qué colección.

Volver

Relaciones de documentos

En esta página