Pourquoi ne pas définir IGNORE_DUP_KEY sur ON?

IGNORE_DUP_KEY = ON indique essentiellement à SQL Server d'insérer des lignes non dupliquées, mais ignore silencieusement les doublons; le comportement par défaut consiste à déclencher une erreur et à annuler la transaction entière lorsqu'il y a des doublons dans une colonne qui ne les autorise pas.Pourquoi ne pas définir IGNORE_DUP_KEY sur ON?

J'ai travaillé avec une tonne de données qui normalement a au moins un doublon quand il ne devrait pas être, donc j'aime utiliser les contraintes UNIQUE quand je sais qu'une valeur ne devrait pas avoir de doublons; Cependant, lorsque j'essaie de charger des données en vrac, la dernière chose que je veux, c'est que 90% d'entre elles soient exécutées et que je rencontre soudainement un doublon et que j'éclate complètement (Oui, je sais que la solution est de s'assurer qu'il n'y a pas de doublons , mais parfois je suis juste remis un tableur rempli de données et dit de le charger dès que possible).

Alors, quelle est la raison pour avoir la valeur par défaut est OFF, et pourquoi ne serait pas vous voulez qu'il soit tout le temps pour que toutes les entrées non-dup réussir alors que vous n'avez pas à vous soucier tous les doublons; les chances sont que les doublons sont là par erreur de toute façon.

Est-ce lié à la performance ou à autre chose? Cela semble être une excellente idée, mais il doit y avoir une raison pour laquelle ce n'est pas le comportement par défaut.

Principalement, y a-t-il une bonne raison pas d'utiliser ceci que je devrais être au courant, ou devrait-il être pour l'évaluation au cas par cas?

Source

2009-02-10 Wayne Molina

Chaque fois qu'il y a un écart par rapport au "normal" dans la base de données, vous voulez probablement le savoir.

Vous avez conservé la clé unique en raison d'une contrainte découlant du besoin métier qui l'a dictée. La base de données maintient juste son côté de l'affaire en disant que vous vouliez que ce soit unique, mais maintenant vous dites quelque chose de contraire. Make up your mind »

Si cela est intentionnel, vous pouvez demander à la base de données de se taire à l'aide IGNORE_DUP_KEY :)

Source

2009-02-11 05:11:34 Learning

Un commentaire, le réglage de l'ignorer ON n'est pas sans conséquences. Si vous avez une colonne d'identité, vous verrez des sauts dans l'identité pour chaque insertion qui a été ignorée en raison d'un doublon. –

L'activation de cette option sur les index non clusterisés entraîne une pénalité sur les performances [Gestion des index uniques avec IGNORE_DUP_KEY] (https://blogs.msdn.microsoft.com/craigfr/2008/01/30/maintaining-unique-indexes-with -ignore_dup_key /) et peut entraîner un verrouillage sévère de la plage avec des lots d'insertion simultanés [Range lock (RS-U) en raison de l'option d'index IGNORE_DUP_KEY] (http://aboutsqlserver.com/tag/locking/). Ainsi, lorsque vous souhaitez insérer plusieurs lignes en une seule fois et ignorer les doublons, appliquez-le uniquement sur la clé en cluster. – eremmel

@eremmel Vous venez de sauver mon bacon, merci pour ce commentaire! Je me suis cogné la tête contre un mur ces derniers jours pour essayer de comprendre pourquoi je recevais des verrous de Range sans isolement sérialisable quand j'ai eu ce petit chatouillement dans mon cerveau à propos de ignore_dup_key causant des problèmes de perf. La recherche rapide m'a conduit à ce post, vous rock! Je souhaite seulement que c'était une réponse complète donc c'était plus évident :) –

Il peut être utilisé comme vérification de santé mentale. Si vous savez qu'il ne devrait pas y avoir de conflits, laissez-le tomber et il échouera rapidement sur les bogues. OTOH pour les sessions de console ad-hoc, je vois votre point.

Source

2009-02-10 19:07:52 BCS

Vraie - Je suppose que cela revient à décider si le scénario de "double entrée" est exceptionnel ou non et si vous devriez faire une erreur, ou simplement l'ignorer. –

Je suppose que c'est peut-être parce que les valeurs par défaut sont définies pour empêcher toute transaction non valide échouer silencieusement. Tout compte fait, je préférerais choisir quand ignorer les conséquences imprévues, mais s'il vous plaît faites le moi savoir à moins que je dise le contraire. Exemple: Si je dépose mon chèque de règlement, j'aimerais que quelqu'un remarque si mon employeur a accidentellement émis des numéros de chèque en double.

Source

2009-02-10 19:12:36 dkretz

C'est vrai aussi. J'imagine que la meilleure raison serait qu'elle fait preuve de prudence et qu'elle génère une erreur à moins que vous ne disiez le contraire. –

les chances sont les doublons sont là par erreur de toute façon.

Je parie qu'ils sont! Ce sont des insectes. Vous voulez certainement savoir à leur sujet! Turing sur IGNORE_DUP_KEYpar défaut est ...

insectes se cachent ...
... en corrompant les données. (Bien sûr, la base de données reste physiquement cohérente, mais les données sont toujours fausses du point de vue de la logique métier.

Ceci est un choix terrible par tous les standards.

Allumez-le dans des circonstances spéciales, puis éliminez-le le plus rapidement possible afin de ne pas masquer accidentellement les bogues.

Source

2012-09-20 13:10:04 usr

Mais la documentation et la question indiquent que vous ne pouvez pas corrompre vos données, car même avec IGNORE_DUP_KEY = ON les doublons ne sont pas autorisés. –

@FrancoisBourgeois ne sais pas ce que vous dites. Les doublons ne sont possibles qu'avec un index non unique, bien sûr. Ce sont des bogues d'application logiques, pas des bogues dans SQL Server. – usr

Il ne corrompt pas les données car il n'insère pas la valeur en double, il saute simplement dessus sans provoquer d'avertissement. – user3071296

J'ai une relation plusieurs-à-plusieurs. J'ai une table de produit à catégorie avec l'index unique, aucune autre donnée que prodid et katid dans la table.

Donc je mets IGNORE_DUP_KEY sur l'index unique (prodid, katid). Je peux donc dire "ajouter un produit (1,2,3) à la catégorie (a, b, c)" sans avoir à vérifier si certains produits sont déjà dans certaines catégories; Je me soucie seulement du résultat final.

Source

2014-03-24 12:32:03

Pourquoi ne pas définir IGNORE_DUP_KEY sur ON?

Répondre

Questions connexes