2009-02-10 3 views
8

IGNORE_DUP_KEY = ON weist SQL Server im Wesentlichen an, nicht duplizierte Zeilen einzufügen, aber alle Duplikate im Hintergrund zu ignorieren. Das Standardverhalten besteht darin, einen Fehler auszulösen und die gesamte Transaktion abzubrechen, wenn sich in einer Spalte Duplikate befinden, die sie nicht zulassen.Warum sollten Sie IGNORE_DUP_KEY NICHT auf ON setzen?

Ich habe mit einer Tonne Daten gearbeitet, die normalerweise mindestens ein Duplikat hat, wenn es nicht sein sollte, also verwende ich gerne UNIQUE Einschränkungen, wenn ich weiß, dass ein Wert keine Duplikate haben sollte; Aber wenn ich versuche, Daten in großen Mengen zu laden, ist das Letzte, was ich will, dass es zu 90% fertig ist und dann plötzlich in ein Duplikat läuft und das Ganze aus der Fassung bringt (Ja, ich weiß, die offensichtliche Lösung ist, dass es keine Duplikate gibt , aber manchmal habe ich nur eine Tabelle mit Daten überreicht und gesagt, um es so schnell wie möglich zu laden).

Also, was ist der Grund, warum der Standard OFF zu sein hat, und warum nicht Sie wollen die ganze Zeit sein, so dass alle nicht-dup Einträge erfolgreich sein, während Sie nicht darum kümmern müssen, irgendwelche Duplikate; Wahrscheinlich sind die Duplikate trotzdem irrtümlich drin.

Bezieht sich dies auf die Leistung oder etwas anderes? Das scheint eine großartige Idee zu sein, aber es muss einen Grund geben, warum es nicht das Standardverhalten ist.

Hauptsächlich, gibt es einen guten Grund nicht zu verwenden, dass ich berücksichtigen sollte, oder sollte es für die Bewertung von Fall zu Fall aus sein?

Antwort

15

Wann immer es eine Abweichung von der "normalen" in der Datenbank gibt, möchten Sie wahrscheinlich darüber wissen.

Sie haben den Schlüssel wegen einiger Zwänge, die sich aus der Geschäftsnotwendigkeit ergeben, die ihn diktiert haben, einmalig gehalten. Die Datenbank hält nur an ihrer Seite fest: "Hey, du wolltest, dass das einzigartig ist, aber jetzt sagst du etwas Gegenteiliges. Make up your mind‘

Wenn das Absicht ist, dass Sie Datenbank fragen kann mit IGNORE_DUP_KEY den Mund zu halten :)

+1

Ein Kommentar, das Setzen der Ignore ist nicht ohne Folgen. Wenn Sie eine Identitätsspalte haben, sehen Sie für jede Einfügung, die aufgrund eines Duplikats ignoriert wurde, Überspringungen in der Identität. –

+1

Wenn diese Option bei nicht geclusterten Indizes aktiviert ist, führt dies zu einer Leistungsbeeinträchtigung [Beibehaltung eindeutiger Indizes mit IGNORE_DUP_KEY] (https://blogs.msdn.microsoft.com/craigfr/2008/01/30/maintaining-unique-indexes-with -ignore_dup_key /) und kann zu schwerwiegenden Bereichssperren bei gleichzeitigem Einfügen von Batches führen [Bereichssperre (RS-U) aufgrund der IGNORE_DUP_KEY-Indexoption] (http://aboutsqlserver.com/tag/locking/). Wenn Sie also viele Zeilen auf einmal einfügen und Duplikate ignorieren möchten, wenden Sie sie nur auf den gruppierten Schlüssel an. – eremmel

+0

@eremmel Sie haben gerade meinen Speck gerettet, danke für diesen Kommentar! Ich habe in den letzten paar Tagen mit meinem Kopf gegen eine Wand gestoßen und versucht herauszufinden, warum ich Range-Locks ohne serialisierbare Isolation bekam, als ich dieses kleine Kitzel in meinem Gehirn über ignore_dup_key bekam, was Perf-Probleme verursachte. Die schnelle Suche führte mich zu diesem Post, du rockst! Ich wünschte nur, dies wäre eine vollständige Antwort, so dass es offensichtlicher war :) –

1

Es kann als eine Gesundheitsprüfung verwendet werden. Wenn Sie wissen, dass es keine Konflikte geben sollte, lassen Sie es aus und es wird schnell auf Fehler stoßen. OTOH für Ad-hoc-Konsolensitzungen, ich verstehe Ihren Standpunkt.

+0

Wahr - Ich denke, es kommt darauf an, zu entscheiden, ob das Szenario der "doppelten Eingabe" ein Ausnahmefall ist oder nicht und ob Sie einen Fehler melden oder ihn einfach ignorieren sollten. –

2

Ich vermute, dass es möglicherweise daran liegt, dass die Standardeinstellungen so eingestellt sind, dass ungültige Transaktionen nicht automatisch fehlschlagen. Alles in allem würde ich lieber wählen, wann unbeabsichtigte Konsequenzen ignoriert werden, aber lass es mich wissen, wenn ich nicht anders sage.

Beispiel: Wenn ich meinen Gehaltsscheck einzahle, möchte ich, dass jemand bemerkt, wenn mein Arbeitgeber versehentlich doppelte Schecknummern ausstellt.

+0

Das stimmt auch. Ich denke, der beste Grund wäre, dass es auf der Seite der Vorsicht liegt und einen Fehler verursacht, wenn Sie es nicht anders sagen. –

2

stehen die Chancen, die Duplikate sind dort ohnehin aus Versehen.

Ich wette, sie sind! Sie sind Fehler. Sie möchten sicherlich über sie wissen! Turing auf IGNORE_DUP_KEYstandardmäßig ist ...

  1. Versteck Bugs ...
  2. ... von Daten korrumpieren. (Natürlich bleibt die Datenbank physikalisch konsistent, aber die Daten sind aus betriebswirtschaftlicher Sicht immer noch falsch.)

Dies ist eine schreckliche Wahl von jedem Standard.

Schalten Sie es unter besonderen Umständen ein und entfernen Sie es dann so schnell wie möglich, damit Sie nicht versehentlich Fehler verstecken.

+1

Aber sowohl die Dokumentation und die Frage besagt, dass Sie Ihre Daten nicht korrumpieren können, denn selbst mit IGNORE_DUP_KEY = ON sind Duplikate nicht erlaubt. –

+0

@FrancoisBourgeois nicht sicher, was Sie sagen. Duplikate sind natürlich nur mit einem nicht eindeutigen Index möglich. Sie sind logische Anwendungsfehler, keine Fehler in SQL Server. – usr

+0

Es beschädigt Daten nicht, weil es den doppelten Wert nicht einfügt, es überspringt es einfach, ohne eine Warnung auszulösen. – user3071296

1

Ich habe eine Viele-zu-viele-Beziehung. Ich habe eine Produkt-zu-Kategorie-Tabelle mit eindeutigen Index, keine anderen Daten als Prodid und Katid in der Tabelle.

Also setze ich IGNORE_DUP_KEY auf den eindeutigen (prodid, katid) Index.

So kann ich sicher sagen "add Produkt (1,2,3) zu Kategorie (a, b, c)" ohne zu prüfen, ob einige Produkte in einigen Kategorien schon sind; Ich interessiere mich nur für das Endergebnis.

Verwandte Themen