En écrivant une requête un autre jour, une pensée m'est venue et est restée dans mon esprit.
Qu'est-ce qui est préférable, d'abord vérifier si une valeur pour une colonne unique existe, puis insérer ou insérer et laisser db générer une erreur de contrainte unique? Cela importera-t-il même?
Edit: Comme suggéré ci-dessous pour répondre que ce problème dépend de la base de données, j'ajoute la balise postgresql.
Réponses:
Je ne pense pas que votre question soit vraiment indépendante des bases de données. La bonne réponse peut dépendre des détails d'implémentation, qui peuvent varier d'un fournisseur à l'autre et changer avec la prochaine version. Je testerais sous simultané avant de choisir une approche sur n'importe quel SGBDR.
En ce moment, sur SQL Server 2008 R2, j'utilise ce qui suit:
Faible simultanéité et faible quantité de modifications. Pour enregistrer une seule ligne, je sérialise à l'aide de sp_getapplock et utilise MERGE. Je teste les contraintes sous une concurrence élevée pour vérifier que cela fonctionne.
Concurrence et / ou volume plus élevés. Pour éviter la concurrence et augmenter les performances, je n'enregistre pas une ligne à la fois. J'accumule des modifications sur mon serveur d'applications et j'utilise des TVP pour enregistrer des lots. Pourtant, pour éviter les problèmes liés à la concurrence, je sérialise en utilisant sp_getapplock avant le MERGE. Encore une fois, je soumets à un test de stress sous forte concurrence pour vérifier que cela fonctionne.
En conséquence, nous avons de bonnes performances et aucun problème lié à la concurrence en production: pas de blocages, pas de violation de PK / contraintes uniques, etc.
Laissez la base de données générer une erreur.
Tester d'abord n'est pas sûr pour la simultanéité car vous obtiendrez éventuellement une collision car 2 threads peuvent passer le "NON EXIST" et les deux essaieront d'écrire. Cela s'applique à la fois aux stratégies de verrouillage "LECTURE COMMISE" et MVCC / Snapshot.
Vous pouvez utiliser des conseils de verrouillage pour forcer l'isolement, mais vous réduisez les performances.
J'appelle cela le modèle JFDI (lien SO). Pour la «mise à jour s'il existe», consultez cette page ici: Besoin d'aide pour résoudre le scénario de blocage de SQL Server 2005 . Ce sont SQL Server. MySQL a INSERT IGNORE qui gère cela avec élégance. Pas sûr du reste
MERGEqui ont peut-être résolu les observations de Paul, mais je n'ai pas testé cela à des taux d'émission élevés. Surtout parce que je n'ai pas encore entraîné mon cerveau à comprendre cette syntaxe.