Controllo per record duplicati VS try/catch Unico vincolo di chiave

Question

Ho una tabella di database con un vincolo di chiave univoco definito per evitare che si verifichino record duplicati.

Sono curioso se è una cattiva pratica NON controllare manualmente i record duplicati prima di eseguire un'istruzione INSERT sulla tabella.

In altre parole, dovrei eseguire un'istruzione SELECT utilizzando una clausola WHERE che controlla i valori duplicati del record che sto per INSERIRE. Se viene trovato un record, quindi non eseguire l'istruzione INSERT, altrimenti andare avanti ed eseguire l'INSERT ....

O

Basta eseguire l'istruzione INSERT e try/catch l'eccezione che può essere gettato a causa a una violazione di chiave univoca.

sto pesando i due punti di vista e non riesco a decidere quale è best- 1. Non sprecare una chiamata SELECT per controllare i duplicati quando posso solo trappola per un'eccezione VS 2. Non essere pigro implementando la logica brutto try/catch VS 3. ??? I tuoi pensieri qui ??? :)

Answer 1

Devi davvero usare il metodo try..catch. Può essere meno elegante, ma è infallibile.

Se è presente più di un client che aggiorna questa tabella, un altro client può inserire un record tra l'assegno e l'inserto. È ancora possibile controllare se si desidera, per salvare cercando di fare l'inserto inutilmente. Potrebbe essere un piccolo aumento di prestazioni se è questo che ti preoccupa, ma solo se il numero è un duplicato. Ma ogni volta che lo non è un duplicato, hai pagato una penalità di prestazioni facendo sia una SELECT che un INSERT.

In ogni caso, quali sono le probabilità che ci sia una violazione del vincolo? Probabilmente piccolo, quindi perché preoccuparsi del controllo?

Answer 2

Anche se si controllano i duplicati, è possibile inserire un nuovo elemento dopo averlo controllato e prima di inserirlo, quindi è necessario ancora il blocco try/catch.

Answer 3

Try/catch è più sicuro e più scalabile perché si tocca il tavolo una sola volta. Il try/catch rimuove la gestione degli errori francamente irregolare nelle versioni precedenti

Vedi lesson 4 from this article troppo