In MongoDB, un indice univoco garantisce che un valore particolare in un campo non sia presente in più di un documento. non garantire che un valore sia univoco in un array all'interno di un singolo documento. Questo è spiegato qui nel manuale MongoDB dove si discute di indici multichiave univoci.
Pertanto, un indice univoco non soddisferà le tue esigenze. Eviterà che documenti separati contengano combinazioni duplicate, ma consentirà comunque a un singolo documento di contenere valori duplicati in un array.
L'opzione migliore che hai è cambiare il tuo modello di dati in modo da dividere l'array di oggetti technologyEmployeeRef in documenti separati. La suddivisione in documenti separati ti consentirà di utilizzare un indice univoco per rafforzare l'unicità.
La particolare implementazione da adottare per questa modifica del modello di dati dipenderà dal tuo modello di accesso (che non rientra nell'ambito di questa domanda).
Uno di questi metodi è creare una raccolta TechnologyEmployee che contenga tutti i campi attualmente esistenti nell'array technologyEmployeeRef. Inoltre, questa raccolta TechnologyEmployee avrebbe un campo, come l'e-mail, che ti consentirebbe di associarla a un documento nella raccolta Employee.
Esempio di documento del dipendente
{
....
....
"firstName" : "John",
"lastName" : "Doe",
"email" : "[email protected]",
.....
.....
.....
}
Esempio di documento EmployeeTechnology
{
"email" : "[email protected]",
"technologyCd" : "Java",
"technologyName" : "Java8",
....
.....
"status" : "A"
}
Indice nella raccolta EmployeeTechnology
{'email' : 1, 'technologyCd' : 1}, {unique: true}
Lo svantaggio di questo approccio è che dovresti leggere da due raccolte per avere tutti i dati. Questo inconveniente potrebbe non essere un grosso problema se raramente è necessario recuperare i dati da entrambe le raccolte contemporaneamente. Se hai bisogno di tutti i dati, può essere accelerato tramite l'uso di indici. Con gli indici, potrebbe essere ulteriormente accelerato attraverso l'uso di query coperte.
Un'altra opzione è denormalizzare i dati. Puoi farlo duplicando i dati dei dipendenti a cui devi accedere contemporaneamente ai dati sulla tecnologia.
Documenti di esempio
[
{
....
"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"
}
]
In questo post sul blog di MongoDB, dicono che
Lo faresti solo per i campi che vengono letti frequentemente, che vengono letti molto più spesso di quanto non vengano aggiornati e per i quali non è richiesta una forte coerenza, poiché l'aggiornamento di un valore denormalizzato è più lento, più costoso e non è atomico.
Oppure, come hai già detto, può avere senso lasciare il modello di dati così com'è ed eseguire il controllo dell'unicità sul lato dell'applicazione. Questo potrebbe probabilmente darti le migliori prestazioni di lettura, ma presenta alcuni svantaggi. Innanzitutto, rallenterà le operazioni di scrittura perché l'applicazione dovrà eseguire alcuni controlli prima di poter aggiornare il database.
Potrebbe essere improbabile, ma c'è anche la possibilità che tu possa comunque ritrovarti con dei duplicati. Se sono presenti due richieste back-to-back per inserire lo stesso oggetto EmployeeTechnology nell'array, la convalida della seconda richiesta potrebbe terminare (e passare) prima che la prima richiesta sia stata scritta nel database. Ho visto io stesso uno scenario simile con un'applicazione su cui ho lavorato. Anche se l'applicazione stava verificando l'unicità, se un utente faceva doppio clic su un pulsante di invio, ci sarebbero state voci duplicate nel database. In questo caso, disabilitando il pulsante al primo clic si riduce drasticamente il rischio. Questo piccolo rischio può essere tollerabile, a seconda delle tue esigenze e dell'impatto di avere voci duplicate.
L'approccio più sensato dipende in gran parte dal modello e dai requisiti di accesso. Spero che questo aiuti.
