online - mongodb ventajas y desventajas

Bases de datos de documentos: datos redundantes, referencias, etc.(MongoDB específicamente)

Question

Parece que me encuentro con muchas situaciones en las que la forma adecuada de generar mis datos es dividirla en dos documentos. Digamos que era para una cadena de tiendas y que estaba guardando qué tiendas había visitado cada cliente. Las tiendas y los clientes deben ser partes de datos independientes porque interactúan con muchas otras cosas, pero debemos relacionarlas.

Entonces, la respuesta fácil es almacenar el Id del usuario en el documento de la tienda o el Id de la tienda en el documento del usuario. Muchas veces, sin embargo, desea acceder a otras 1-2 piezas de datos con fines de visualización porque los Id no son útiles. Como tal vez el nombre del cliente o el nombre de la tienda.

1. ¿Suele almacenar un duplicado de todo el documento? ¿O solo almacena los datos que necesitas? Tal vez dependa del tamaño del doc frente a la cantidad que necesita.
2. ¿Cómo manejas el hecho de que tienes datos duplicados? ¿Busca datos cuando cambia? ¿Actualizar los datos en algún intervalo cuando está cargado? ¿Solo se duplica cuando puede permitirse datos obsoletos?

Agradecería su aporte y / o enlaces a cualquier tipo de ''mejores prácticas'' o al menos una discusión bien razonada de estos temas.

Answer 1

Básicamente hay dos escenarios: fresco y rancio .

Datos recientes

Almacenar datos duplicados es fácil. Mantener los datos duplicados es la parte difícil. Entonces, lo más fácil es evitar el mantenimiento, simplemente no almacenando datos duplicados para empezar. Esto es útil principalmente si necesita datos nuevos . Solo almacene las referencias y consulte las colecciones cuando necesite recuperar información.

En este escenario, tendrá algunos gastos generales debido a las consultas adicionales. La alternativa es rastrear todas las ubicaciones de datos duplicados y actualizar todas las instancias de cada actualización. Esto también implica gastos generales, especialmente en relaciones N a M como la que mencionaste. Entonces, de cualquier manera, tendrá un poco de sobrecarga, si necesita datos nuevos. No puedes tener lo mejor de ambos mundos.

Datos obsoletos

Si puede permitirse tener datos obsoletos, las cosas se vuelven mucho más fáciles. Para evitar la sobrecarga de consultas, puede almacenar datos duplicados. Para evitar tener que mantener datos duplicados, no va a almacenar datos duplicados. Al menos no activamente .

En este escenario, también querrá almacenar solo las referencias entre documentos. Luego use un trabajo periódico de reducción de mapas para generar los datos duplicados. Luego puede consultar el resultado de un solo mapa, reducir, en lugar de colecciones separadas. De esta forma evitará la sobrecarga de consultas, pero tampoco tendrá que buscar cambios en los datos.

Resumen

Solo almacena referencias a otros documentos. Si puede permitirse datos obsoletos, utilice trabajos periódicos de reducción de mapas para generar datos duplicados. Evite mantener datos duplicados; es complejo y propenso a errores.

Answer 2

La respuesta aquí realmente depende de cuán actual necesita que sean sus datos.

@Niels tiene un buen resumen aquí, pero creo que es justo señalar que puedes "hacer trampa".

Digamos que desea mostrar las tiendas utilizadas por un usuario. El problema obvio aquí es que no puede "incrustar" la Tienda dentro del Usuario b / c, la Tienda es demasiado importante por sí misma. Pero lo que puedes hacer es insertar algunos datos de la tienda en el usuario.

Simplemente use las cosas que desea para mostrar como "Nombre de la tienda". Entonces su objeto Usuario se vería así:

{
  _id : MongoID(),
  name : "Testy Tester",
  stores : [ 
             { _id : MongoID(), "name" : ''Safeway'' },
             { _id : MongoID(), "name" : ''Walmart'' },
             { _id : MongoID(), "name" : ''Best Buy'' }
            ]
}

De esta forma, puede visualizar la vista típica de "cuadrícula", pero requiere un enlace para obtener más datos sobre la tienda.

Answer 3

Para responder a sus preguntas directas:

1. Sin duplicados
2. Sin duplicados

;)

Los únicos duplicados que debe tener son valores "simples" como los pesos (que pueden ser los mismos, pero no son más eficientes en tiempo o espacio para almacenarlos por separado) y los identificadores que hacen referencia a otro objeto (que son valores duplicados) , pero mucho más pequeño y más manejable que los datos de objetos duplicados que reemplazan).

Ahora, para responder a su situación, lo que desea es una relación de Muchos a Muchos. La solución usual aquí es hacer una tercera tabla / colección "a través" o "puente", probablemente llamada StoreUsers:

StoreUsers
----------
storeuser_id
store_id
user_id

Agregue un registro a esto para cada enlace entre tiendas y usuarios, ya sea para una tienda diferente, un usuario diferente o un grupo de usuarios en una tienda. Luego puede buscar esto de forma independiente, ya sea para la tienda o el usuario. MongoDB también defiende este enfoque; no es específico de RDBMS.