Je pense que dans la plupart des cas, les différences entre ces deux seront suffisamment petites pour que le choix soit principalement motivé par le choix de l'implémentation qui finit par être la plus compréhensible pour quelqu'un qui regarde le code pour la première fois.
Cependant, je pense que la gestion des exceptions a quelques petits avantages :
-
La gestion des exceptions évite une condition de concurrence potentielle. La méthode "vérifier, puis insérer" peut échouer si un autre processus insère un enregistrement entre votre vérification et votre insertion. Donc, même si vous faites "vérifier puis insérer", vous voulez toujours gérer les exceptions sur l'insertion et si vous faites déjà la gestion des exceptions de toute façon, vous pouvez aussi bien supprimer la vérification initiale.
-
Si votre code n'est pas une procédure stockée et doit interagir avec la base de données via le réseau (c'est-à-dire que l'application et la base de données ne sont pas sur la même boîte), alors vous voulez éviter d'avoir deux appels réseau séparés (un pour le contrôle et le autre pour l'insertion) et le faire via la gestion des exceptions fournit un moyen simple de gérer le tout avec un seul appel réseau. Maintenant, il existe des tonnes de façons d'appliquer la méthode "vérifier puis insérer" tout en évitant le deuxième appel réseau, mais le simple fait d'attraper l'exception est probablement le moyen le plus simple de s'y prendre.
D'autre part, la gestion des exceptions nécessite une contrainte d'unicité (qui est en réalité un index unique), qui s'accompagne d'un compromis en termes de performances :
- La création d'une contrainte unique sera lente sur de très grandes tables et entraînera une baisse des performances à chaque insertion dans cette table. Sur les bases de données vraiment volumineuses, vous devez également budgétiser l'espace disque supplémentaire consommé par l'index unique utilisé pour appliquer la contrainte.
- D'un autre côté, cela peut accélérer la sélection dans le tableau si vos requêtes peuvent tirer parti de cet index.
Je noterais également que si vous êtes dans une situation où ce que vous voulez réellement faire est de "mettre à jour l'insertion d'autre" (c'est-à-dire si un enregistrement avec la valeur unique existe déjà, vous souhaitez mettre à jour cet enregistrement, sinon vous insérez un nouveau record) alors ce que vous voulez réellement utiliser est la méthode UPSERT de votre base de données particulière, si elle en a une. Pour SQL Server et Oracle, il s'agirait d'une instruction MERGE.
