J'ai une table de base de données qui a une contrainte clé unique définie pour éviter les enregistrements en double survenus.
Je suis curieux s'il s'agit d'une mauvaise pratique de ne pas rechercher manuellement les enregistrements en double avant d'exécuter une instruction insertion sur la table.
En d'autres termes, devrais-je exécuter une instruction SELECT à l'aide d'une clause WHERE qui vérifie les valeurs dupliquées de l'enregistrement que je suis sur le point d'insérer. Si un enregistrement est trouvé, alors n'exécutez pas l'instruction insertion, sinon allez-y et exécutez l'insert ....
ou
Exécutez simplement l'instruction insert et essayez / attrapez l'exception pouvant être lancée en raison d'une violation clé unique.
Je pèse les deux perspectives et je ne peux pas décider lequel est le meilleur 1. Ne perdez pas un appel Select pour vérifier les doublons lorsque je peux simplement piéger pour une exception vs 2. Ne soyez pas paresseux en mettant en œuvre la micly try / attraper la logique VS 3. ??? Vos pensées ici ??? :)
3 Réponses :
Même si vous vérifiez que vous vérifiez un nouvel élément, un nouvel élément peut être inséré après avoir vérifié et avant de vous insérer, vous avez donc encore besoin d'essayer / prenez le bloc.
Vous devez vraiment utiliser la méthode try..catch. Il peut être moins élégant, mais il est infaillible.
S'il y a plus d'un client à mettre à jour cette table, un autre client peut insérer un enregistrement entre votre chèque et votre insert. Vous pouvez toujours vérifier si vous voulez, économiser d'essayer de faire l'insert inutilement. Cela pourrait être une petite performance augmenter si c'est ce que vous êtes inquiet, mais seulement s'il y a est un duplicata. Mais chaque fois qu'il n'est pas un duplicata, vous avez payé une pénalité de performance en faisant à la fois un SELECT et un insert.
Quoi qu'il en soit, quelles sont les chances qu'il y aura une violation de contrainte? Probablement petit, alors pourquoi déranger avec le chèque?
Essayer / Catch est plus sûr et plus évolutif, car vous ne toucherez que la table une fois. L'essai / attrape supprime la gestion des erreurs franchement erratiques dans les versions antérieures
voir Leçon 4 de Cet article trop