Por el contrario, las soluciones 1 y 2 son su mejor opción. La solución 3 se puede considerar cuando la frecuencia de actualización/creación es muy inferior en comparación con la frecuencia de lectura de proyectos y usuarios, ya que, aunque para actualizar/crear, se requieren dos consultas, la facilidad de lectura se compensará.
Para elegir entre la solución 1 y 2, debe considerar las frecuencias de lectura. ¿Necesitará proyectos de un usuario o usos de un proyecto con más frecuencia y elija de acuerdo con eso? Si cree que ambos tienen relativamente la misma frecuencia, es mejor mantener el objeto de usuario lo menos agrupado posible. Independientemente de la opción que elija, considere mantener un index en la matriz que almacena el _id s (de proyectos o usuarios).
Por ej.
userSchema = new Schema(
{//otherstuff
project_ids: [{type: Schema.Types.ObjectId, ref: 'Project'}})
...
})
userSchema.index({'project_ids':1})
o
projectSchema = new Schema(
{//otherstuff
user_ids: [{type: Schema.Types.ObjectId, ref: 'User'}})
...
})
projectSchema.index({'user_ids':1})
Mantener un índice en la matriz de _id mejorará enormemente la velocidad de sus consultas en el lado donde teme que habrá una sobrecarga significativa.
Pero mantén el index solo si esta relación es una relación importante con muchas consultas en curso. Si esta es solo una característica secundaria de su proyecto, puede prescindir de without un índice también.
Si el usuario puede hacer muchas cosas y tiene muchas relaciones, necesitará ese objeto de usuario constantemente en toda su aplicación, por lo que si su aplicación no es específica del proyecto, sería mejor no poner las identificaciones del proyecto en el esquema del usuario. . Pero como solo estamos poniendo los identificadores, no es una gran sobrecarga de todos modos. No hay necesidad de preocuparse por eso.
Índice de registro en ambas matrices:sí, por supuesto. Pero cuando opta por la solución 3, no necesita un índice en absoluto, ya que no realizará una consulta para obtener la lista de proyectos de un usuario o la lista de usuarios en un proyecto. La solución 3 hace que leer sea muy fácil pero escribir sea un poco engorroso. Pero como mencionaste, tu caso de uso implica reading>>writing , opte por la solución 3, pero siempre existe el peligro de incoherencias en los datos de las que debe ocuparse.
La indexación simplemente hace las cosas más rápidas. Revisa los documentos y busca un poco en Google. Nada sofisticado. Consultar matrices indexadas es más eficiente que las matrices normales. por ej. Supongamos que usa la solución 2. Almacene los ID del proyecto en el campo project_ids.
Puede obtener los proyectos de un usuario fácilmente. Esto es sencillo.
Pero para obtener usuarios de project1. Necesita una consulta como esta.
User.find({project_ids:project._id},function(err,docs){
//here docs will be the list of the users of project1
})
//The above query might be slow if the user base is large.
//But it can be improved vastly by indexing the project_ids field in the User schema.
De manera similar para la solución 1. Cada proyecto tiene un campo user_ids. Supongamos que tenemos un usuario 1. Para obtener los proyectos del usuario, hacemos la siguiente consulta
Project.find({user_ids:user1._id},function(err,docs){
//here docs will be the projects of user1
//But it can be improved vastly by indexing the user_ids field in the Project schema.
Si está pensando en la solución 1 frente a la solución 2, supongo que la solución 1 es mejor. Puede haber casos en los que necesite un usuario sin sus proyectos, pero las posibilidades de requerir el proyecto sin usuarios son bastante bajas. Pero depende de su caso de uso exacto.
