En MongoDB, un índice único asegura que un valor particular en un campo no esté presente en más de un documento. no garantiza que un valor es único en una matriz dentro de un solo documento. Esto se explica aquí en el Manual de MongoDB, donde se analizan los índices multiclave únicos.
Por lo tanto, un índice único no satisfará sus requisitos. Evitará que los documentos separados contengan combinaciones duplicadas, pero aún permitirá que un solo documento contenga valores duplicados en una matriz.
La mejor opción que tiene es cambiar su modelo de datos para dividir la matriz de objetos technologyEmployeeRef en documentos separados. Dividirlo en documentos separados le permitirá usar un índice único para hacer cumplir la unicidad.
La implementación particular que se debe tomar para este cambio en el modelo de datos dependería de su patrón de acceso (que está fuera del alcance de esta pregunta).
Una forma de hacerlo es crear una colección TechnologyEmployee que tenga todos los campos que existen actualmente en la matriz technologyEmployeeRef. Además, esta colección TechnologyEmployee tendría un campo, como correo electrónico, que le permitiría asociarlo con un documento en la colección Employee.
Ejemplo de documento de empleado
{
....
....
"firstName" : "John",
"lastName" : "Doe",
"email" : "[email protected]",
.....
.....
.....
}
Ejemplo de documento de tecnología para empleados
{
"email" : "[email protected]",
"technologyCd" : "Java",
"technologyName" : "Java8",
....
.....
"status" : "A"
}
Índice en la colección EmployeeTechnology
{'email' : 1, 'technologyCd' : 1}, {unique: true}
La desventaja de este enfoque es que necesitaría leer de dos colecciones para tener todos los datos. Este inconveniente puede no ser un gran problema si rara vez necesita recuperar los datos de ambas colecciones al mismo tiempo. Si necesita todos los datos, puede acelerarlos mediante el uso de índices. Con los índices, podría acelerarse aún más mediante el uso de consultas cubiertas.
Otra opción es desnormalizar los datos. Haría esto duplicando los datos de Empleado a los que necesita acceder al mismo tiempo que los datos de Tecnología.
Documentos de muestra
[
{
....
"firstName" : "John",
"lastName" : "Doe",
"email" : "[email protected]",
.....
"technologyCd" : "Java",
"technologyName" : "Java8",
....
"status" : "A"
},
{
....
"firstName" : "John",
"lastName" : "Doe",
"email" : "[email protected]",
.....
"technologyCd" : "Spring",
"technologyName" : "Spring Boot2",
....
"status" : "A"
}
]
En esta publicación de blog de MongoDB, dicen que
Haría esto solo para los campos que se leen con frecuencia, se leen con mucha más frecuencia de lo que se actualizan y donde no requiere una consistencia sólida, ya que actualizar un valor desnormalizado es más lento, más costoso y no es atómico.
O como ya mencionó, puede tener sentido dejar el modelo de datos tal como está y realizar la verificación de unicidad en el lado de la aplicación. Es probable que esto le brinde el mejor rendimiento de lectura, pero tiene algunas desventajas. Primero, ralentizará las operaciones de escritura porque la aplicación necesitará ejecutar algunas comprobaciones antes de que pueda actualizar la base de datos.
Puede ser poco probable, pero también existe la posibilidad de que aún pueda terminar con duplicados. Si hay dos solicitudes consecutivas para insertar el mismo objeto EmployeeTechnology en la matriz, entonces la validación de la segunda solicitud puede finalizar (y pasar) antes de que la primera solicitud se haya escrito en la base de datos. Yo mismo he visto un escenario similar con una aplicación en la que trabajé. Aunque la aplicación estaba comprobando la unicidad, si un usuario hacía doble clic en un botón de envío, terminaría habiendo entradas duplicadas en la base de datos. En este caso, deshabilitar el botón en el primer clic redujo drásticamente el riesgo. Este pequeño riesgo puede ser tolerable, según sus requisitos y el impacto de tener entradas duplicadas.
El enfoque que tenga más sentido depende en gran medida de su patrón de acceso y sus requisitos. Espero que esto ayude.
