sql >> Base de Datos >  >> NoSQL >> MongoDB

MongoDB - estructura de padres e hijos

Debe considerar el tipo de consultas que deberá realizar y la frecuencia con la que se necesitará cada tipo. Cuando estaba trabajando en algo similar, se me ocurrieron seis acciones posibles:

  • Hacer algo con el padre
  • Haz algo con los niños
  • Hacer algo con los antepasados ​​(padres de padres, padres de padres de padres, etc.)
  • Hacer algo con los descendientes (hijos de hijos, hijos de hijos de hijos, etc.)
  • Cambiar relaciones (agregar/mover/eliminar nodos en la jerarquía)
  • Cambiar los datos principales en el nodo actual (por ejemplo, cambiar el valor en el campo "título")

Querrá estimar qué tan importante es cada uno de estos para su aplicación.

Si la mayor parte de su trabajo consiste en trabajar con datos almacenados para un artículo determinado, incluidos su padre inmediato y sus hijos, la primera idea es de lo más útil. De hecho, en MongoDB, es bastante común colocar toda la información que necesita en el mismo documento en lugar de hacer referencia a ella externamente, de modo que solo necesita recuperar una cosa y trabajar con esos datos. Sin embargo, las últimas cuatro acciones de la lista son más complicadas.

En particular, deberá atravesar el árbol para recuperar antepasados ​​y descendientes en este caso, moviéndose a través de documentos intermedios y siguiendo una ruta, aunque solo le interese el último documento de la ruta. Esto puede ser lento para jerarquías largas. Cambiar las relaciones puede requerir mover mucha información en varios documentos debido a todos los datos presentes en cada uno. Pero incluso cambiar un solo campo como "título" puede ser molesto, porque debe considerar el hecho de que este campo está presente en varios documentos diferentes, ya sea como campo principal o debajo de los campos principal o secundario.

Básicamente, tu primera idea funciona mejor en más aplicaciones estáticas donde no cambiará mucho los datos después de crearlos inicialmente, pero donde necesita leerlos regularmente.

La documentación de MongoDB tiene cinco enfoques recomendados para manejar estructuras en forma de árbol (jerárquicas). Todos ellos tienen diferentes ventajas y desventajas, aunque todos facilitan la actualización de los datos principales de un artículo al solo tener que hacerlo en un documento.

  • Referencias de padres :cada nodo contiene una referencia a su padre.
  • Ventajas :<último>
  • Búsqueda principal rápida (búsqueda por "_id" =el título de su documento, devolver el campo "principal")
  • Búsqueda rápida de niños (búsqueda por "principal" =el título de su documento, que devolverá todos los documentos secundarios)
  • Actualizar relaciones es solo cuestión de cambiar el campo "principal"
  • Cambiar los datos subyacentes requiere cambios en un solo documento
  • Desventajas :<último>
  • La búsqueda por antepasados ​​y descendientes es lenta y requiere un recorrido
  • Referencias de niños :cada nodo contiene una matriz de referencia a sus hijos
    • Ventajas :<último>
    • Recuperación rápida de elementos secundarios (devuelve la matriz de elementos secundarios)
    • Actualización rápida de relaciones (simplemente actualice la matriz de niños cuando sea necesario)
  • Desventajas :<último>
  • Encontrar un padre requiere buscar su _id en todas las matrices secundarias de todos los documentos hasta que lo encuentre (ya que el padre contendrá el nodo actual como hijo)
  • La búsqueda de antepasados ​​y descendientes requiere recorridos del árbol
  • Matriz de antepasados :cada nodo contiene una referencia a una matriz de sus ancestros y su padre
    • Ventajas :<último>
    • Recuperación rápida de ancestros (no es necesario atravesar para encontrar uno específico)
    • Fácil búsqueda de padres e hijos siguiendo el enfoque de "Referencias de padres"
    • Para encontrar descendientes, simplemente busque los antepasados, porque todos los descendientes deben tener los mismos antepasados
  • Desventajas :<último>
  • Debe preocuparse por mantener actualizada la matriz de antepasados, así como el campo principal, siempre que haya un cambio en las relaciones, a menudo en varios documentos.
  • Caminos materializados :cada nodo contiene una ruta a sí mismo - requiere regex
    • Ventajas :<último>
    • Fácil de encontrar hijos y descendientes usando expresiones regulares
    • Puede usar una ruta para recuperar padres y antepasados
    • Flexibilidad, como encontrar nodos por rutas parciales
  • Desventajas :<último>
  • Los cambios de relación son difíciles, ya que pueden requerir cambios en las rutas de varios documentos
  • Conjuntos anidados :Cada nodo contiene un campo "izquierdo" y "derecho" para ayudar a encontrar subárboles
    • Ventajas :<último>
    • Fácil de recuperar descendientes de una manera óptima al buscar entre "izquierda" y "derecha"
    • Al igual que el enfoque "Referencia de padres", es fácil encontrar padres e hijos
  • Desventajas :<último>
  • Necesita atravesar la estructura para encontrar antepasados
  • Los cambios de relación funcionan peor aquí que cualquier otra opción porque es posible que sea necesario cambiar cada documento en el árbol para asegurarse de que "izquierda" y "derecha" sigan teniendo sentido una vez que algo cambie en la jerarquía
  • Los cinco enfoques se analizan con más detalle en la documentación de MongoDB .

    Tu segunda idea combina los enfoques de "Referencias principales" y "Referencias secundarias" discutidos anteriormente. Este enfoque facilita la búsqueda de los elementos secundarios y principales y facilita la actualización de las relaciones y los datos principales de un artículo (aunque debe actualizar los campos principal y secundario), pero aún debe recorrerlo. encontrar antepasados ​​y descendientes.

    Si está interesado en encontrar antepasados ​​y descendientes (y le importa más esto que poder actualizar fácilmente las relaciones), puede considerar agregar una matriz de antepasados ​​a su segunda idea para que también sea más fácil consultar antepasados ​​y descendientes. Por supuesto, actualizar las relaciones se convierte en un verdadero dolor si haces esto.

    Conclusión:

    • En última instancia, todo depende de qué acciones se necesitan más. Dado que está trabajando con artículos, cuyos datos subyacentes (como el título) pueden cambiar con frecuencia, es posible que desee evitar la primera idea, ya que necesitaría actualizar no solo el documento principal de ese artículo, sino también todos los documentos secundarios, así como el padre.

    • Su segunda idea facilita la recuperación del padre y los hijos inmediatos. Actualizar las relaciones tampoco es demasiado difícil (sin duda es mejor que algunas de las otras opciones disponibles).

    • Si realmente desea facilitar la búsqueda de antepasados ​​y descendientes a expensas de actualizar las relaciones con la misma facilidad, elija incluir una matriz de referencias de antepasados.

    • En general, intente minimizar la cantidad de recorridos requeridos, ya que requieren ejecutar algún tipo de iteración o recursión para obtener los datos que desea. Si valora la capacidad de actualizar las relaciones, también debe elegir una opción que cambie menos nodos en el árbol (referencias principales, referencias secundarias y su segunda idea puede hacer esto).