mongodb - mejor práctica para la categoría anidada en Mongo y Meteor

database-design mongodb-query

Question

Quiero manejar la categoría anidada en el marco Mongo y Meteor para varios Anuncios. Por ejemplo, así:

Los objetos publicitarios tienen un campo de categoría como este:

MainCategory_1 > SubCategory_1.1 > SubCategory_1.1.1 > SubCategory_1.1.1.1 > { Ad_1 HERE }
> SubCategory_1.2 > SubCategory_1.2.1
> SubCategory_1.3
MainCategory_2 > SubCategory_2.1 > SubCategory_2.1.1 > SubCategory_2.1.1.1
> SubCategory_2.2 > SubCategory_2.2.1
> SubCategory_2.3 

por ejemplo, el objeto Ad_1 pertenece a SubCategory_1.1.1.1

Y también quiero acceder a Ad_1 con consultas como esta:

All MainCategory_1 All SubCategory_1.1 All SubCategory_1.1.1 All SubCategory_1.1.1.1 Y All SubCategory3

Tengo dos enfoques:

1. Almacena cat_id para cada objeto y cat_id resultado en consultas múltiples.
2. Almacene categoría como cadena de ruta y consulta en ese campo de cadena. Me gusta esta respuesta

Quiero saber cuál es mejor?

¿Conoces otro enfoque con mejor rendimiento y simplicidad?

Answer 1

Depende en gran medida de la relación entre sus objetos (es decir, la relación entre el número de objetos en cada lado de la relación y la frecuencia de las actualizaciones) por lo que depende de su aplicación y sus requisitos.

Un buen recurso para mirar (que puede tomar como ''mejor práctica'') es el blog de MongoDB sobre la desnormalización:

http://blog.mongodb.org/post/87200945828/6-rules-of-thumb-for-mongodb-schema-design-part-1

http://blog.mongodb.org/post/87892923503/6-rules-of-thumb-for-mongodb-schema-design-part-2

http://blog.mongodb.org/post/88473035333/6-rules-of-thumb-for-mongodb-schema-design-part-3

en resumen, porque es un tema amplio: estamos hablando de la relación NN, y depende de la relación de N

Si los objetos son inmutables, se recomienda anidarlos en otro objeto, ya que no tendrá que lidiar con las actualizaciones y la búsqueda se vuelve trivial.

Si los objetos no son inmutables, debe ponderar el costo de las actualizaciones frente al costo de buscar en una colección para buscar ID y buscar en la otra colección los objetos asociados con esos ID.