IGNORE_DUP_KEY = ON weist SQL Server im Wesentlichen an, nicht duplizierte Zeilen einzufügen, ignoriert jedoch automatisch alle Duplikate. Das Standardverhalten besteht darin, einen Fehler auszulösen und die gesamte Transaktion abzubrechen, wenn sich in einer Spalte Duplikate befinden, die sie nicht zulassen.
Ich habe mit einer Unmenge von Daten gearbeitet, die normalerweise mindestens ein Duplikat enthalten, wenn das nicht der Fall sein sollte. Daher verwende ich gerne UNIQUE constraints, 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 gefüllt und gesagt, um es so schnell wie möglich zu laden).
Was ist also der Grund dafür, dass der Standardwert OFF ist und warum nicht gewünscht wird, dass er ständig aktiv ist, damit alle nicht-dup-Einträge erfolgreich ausgeführt werden können? mach dir keine Gedanken über Duplikate; Die Wahrscheinlichkeit ist, dass die Duplikate sowieso schon da sind.
Geht es um Leistung oder etwas anderes? Das scheint eine großartige Idee zu sein, aber es muss einen Grund geben, warum es nicht das Standardverhalten ist.
Gibt es hauptsächlich einen guten Grund, dieses zu verwenden, von dem ich wissen sollte, oder sollte es von Fall zu Fall ausgewertet werden?
Wann immer es eine Abweichung vom "normalen" in der Datenbank gibt, möchten Sie wahrscheinlich etwas darüber wissen.
Sie haben den Schlüssel wegen einiger Zwänge, die sich aus dem geschäftlichen Zwang ergaben, der ihn diktiert hat, einzigartig gemacht. Die Datenbank hält nur an ihrer Seite fest: "Hey, du wolltest, dass das einzigartig ist, aber jetzt sagst du etwas Gegenteiliges. Entscheide dich '
Wenn dies beabsichtigt ist, können Sie die Datenbank bitten, den Mund zu halten, indem Sie IGNORE_DUP_KEY:)
verwendenIch nehme an, 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 zu ignorieren, aber bitte lass es mich wissen, wenn ich nicht anders sage.
Beispiel: Wenn ich meinen Gehaltsscheck hinterlasse, möchte ich, dass jemand bemerkt, wenn mein Arbeitgeber versehentlich doppelte Schecknummern ausstellt.
Die Wahrscheinlichkeit ist, dass die Duplikate sowieso irrtümlich da sind.
Ich wette, das sind sie! Sie sind Fehler. Sie möchten sicherlich über sie wissen! Turing auf IGNORE_DUP_KEY ist standardmäßig ...
Dies ist eine schreckliche Wahl für jeden 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.
Ich habe eine Viele-zu-Viele Beziehung. Ich habe eine Produkt-zu-Kategorie-Tabelle mit eindeutigen Index, keine anderen Daten als Prodid und Kattid in der Tabelle.
Also setze ich IGNORE_DUP_KEY auf den eindeutigen Index (prodid, katid).
Also kann ich ruhig sagen: "füge Produkt (1,2,3) zur Kategorie (a, b, c) hinzu", ohne prüfen zu müssen, ob einige Produkte schon in einigen Kategorien sind; Ich interessiere mich nur für das Endergebnis.
Tags und Links sql-server tsql database-design