Wenn auf „ON UPDATE CASCADE“ verwenden

Question

Ich verwende „ON DELETE CASCADE“ regelmäßig, aber ich nie „ON UPDATE CASCADE“, wie ich in welcher nicht so sicher bin Situation es nützlich sein wird.

Aus Gründen der Diskussion ließ einige Codes sehen.

CREATE TABLE parent (
    id INT NOT NULL AUTO_INCREMENT,
    PRIMARY KEY (id)
);

CREATE TABLE child (
    id INT NOT NULL AUTO_INCREMENT, parent_id INT,
    INDEX par_ind (parent_id),
    FOREIGN KEY (parent_id)
        REFERENCES parent(id)
        ON DELETE CASCADE
);

Für „ON DELETE CASCADE“, wenn ein Elternteil mit einem id gelöscht wird, wird ein Datensatz in Kind mit parent_id = parent.id automatisch gelöscht. Dies sollte kein Problem sein.

1. Das bedeutet, dass "ON UPDATE CASCADE" wird das gleiche tun, wenn id des Mutter aktualisiert wird?

2. Wenn (1) wahr ist, bedeutet dies, dass es keine Notwendigkeit „ON UPDATE CASCADE“ zu verwenden ist, wenn parent.id nicht aktualisierbar ist (oder wird nie aktualisiert werden), wie wenn es AUTO_INCREMENT ist oder immer sein TIMESTAMP gesetzt . Ist das richtig?

3. Wenn (2) nicht wahr ist, in welcher anderen Art von Situation sollten wir "ON UPDATE CASCADE"?

verwenden

4. Was passiert, wenn ich (aus irgendeinem Grunde), um die child.parent_id zu aktualisieren zu sein, bestehend etwas nicht, wird es dann automatisch gelöscht?

Nun, ich weiß, kann ein Teil der Frage über sein Test programmically zu verstehen, aber ich möchte auch wissen, ob jede dieser Datenbank-Anbieter abhängig ist oder nicht.

Bitte etwas Licht.

Answer 1

Es ist wahr, dass, wenn Ihr Primärschlüssel nur ein Identitätswert auto erhöht ist, würden Sie keine wirkliche Verwendung für ON UPDATE CASCADE haben.

Allerdings, sagen wir mal, dass Ihr Primärschlüssel eine 10-stellige UPC-Strichcode ist und wegen der Expansion, müssen Sie es auf eine 13-stellige UPC-Strichcode ändern. In diesem Fall ON UPDATE CASCADE Sie erlauben würde, den Primärschlüsselwert und alle Tabellen zu ändern, die Fremdschlüssel-Referenzen auf den Wert haben wird entsprechend geändert werden.

In Bezug auf # 4, wenn Sie das Kind ID, um etwas zu ändern, die in der übergeordneten Tabelle nicht existiert (und Sie haben die referentielle Integrität), sollten Sie einen Fremdschlüssel Fehler.

Answer 2

1. Ja, bedeutet dies, dass zum Beispiel, wenn Sie alle Kinder parent_id die von 10 UPDATE parent SET id = 20 WHERE id = 10 tun auch 20 aktualisiert werden

2. Wenn Sie das Feld nicht aktualisieren der Fremdschlüssel verweist, ist diese Einstellung nicht erforderlich

3. Kann nicht denken Sie an jede andere Verwendung.

4. Sie können nicht tun, da die Fremdschlüssel fehlschlagen würde.

Answer 3

Ich glaube, Sie haben so ziemlich die Punkte genagelt!

Wenn Sie Datenbank-Design Best Practices und Ihre primäre Schlüssel ist nie aktualisierbar folgen (was ich denke immer der Fall ohnehin sein sollte), dann müssen Sie nie wirklich die ON UPDATE CASCADE Klausel.

Zed einen guten Punkt gemacht, dass, wenn Sie einen natürlichen verwenden Schlüssel (zB ein regelmäßiges Feld aus Ihrer Datenbank-Tabelle) als Primärschlüssel, dann kann es sicher sein, Situationen, in denen Sie benötigen, um Ihre Primärschlüssel zu aktualisieren. Ein weiteres aktuelles Beispiel wäre die ISBN (International Standard Book Number) sein, die vor 10 bis 13 Ziffern + Zeichen nicht zu lange verändert.

Dies ist nicht der Fall, wenn Sie verwenden Surrogat wählen (zB künstlich vom System generiert) Schlüssel als Primärschlüssel (die in allen meine bevorzugte Wahl, als die meist seltenen Fälle wäre).

Also am Ende: Wenn Ihr Primärschlüssel nie ändert, dann müssen Sie nie die ON UPDATE CASCADE Klausel

.

Marc

Answer 4

Vor ein paar Tagen habe ich ein Problem mit dem Auslöser hatte, und ich habe herausgefunden, dass ON UPDATE CASCADE nützlich sein kann. Werfen Sie einen Blick auf dieses Beispiel (PostgreSQL):

CREATE TABLE club
(
    key SERIAL PRIMARY KEY,
    name TEXT UNIQUE
);

CREATE TABLE band
(
    key SERIAL PRIMARY KEY,
    name TEXT UNIQUE
);

CREATE TABLE concert
(
    key SERIAL PRIMARY KEY,
    club_name TEXT REFERENCES club(name) ON UPDATE CASCADE,
    band_name TEXT REFERENCES band(name) ON UPDATE CASCADE,
    concert_date DATE
);

In meiner Ausgabe hatte ich für die Aktualisierung Konzert der Tabelle einige zusätzliche Operationen (Trigger) zu definieren. Diese Vorgänge hatten club_name und band_name zu ändern. Ich war nicht in der Lage, es zu tun, weil die Referenz. Ich konnte nicht Konzert ändern und dann mit Club und Band Tabellen beschäftigen. Ich konnte nicht tun es auch in die andere Richtung. ON UPDATE CASCADE war der Schlüssel um das Problem zu lösen.

Answer 5

Mein Kommentar ist in erster Linie in Bezug auf 3 # Punkt: unter welchen Umständen ON UPDATE CASCADE anwendbar ist, wenn wir gehen davon aus, dass der übergeordnete Schlüssel nicht aktualisierbar ist? Hier ist ein Fall.

ich mit einem Replikationsszenario zu tun habe, in denen mehrere Satelliten Datenbanken müssen mit einem Master zusammengeführt werden. Jeder Satellit ist, Erzeugen von Daten, auf den gleichen Tabellen, so Verschmelzen der Tabellen an den Master Verletzungen der Eindeutigkeitsbedingung führt. Ich versuche, ON UPDATE CASCADE als Teil einer Lösung zu verwenden, in dem ich während jeden merge die Schlüssel erneut Zuwachs. ON UPDATE sollte CASCADE diesen Prozess vereinfachen, indem ein Teil des Prozesses zu automatisieren.

Answer 6

Es ist eine ausgezeichnete Frage, ich die gleiche Frage hatte gestern. Ich dachte an dieses Problem, speziell GESUCHT wenn existierte so etwas wie „ON UPDATE CASCADE“ und zum Glück die Designer von SQL auch darüber nachgedacht hatte. Ich stimme mit Ted.strauss, und ich bemerkte auch Noran Fall.

Wann habe ich es verwenden? Wie Ted wies darauf hin, wenn Sie mehrere Datenbanken gleichzeitig behandeln, und die Änderung in einem von ihnen, in einer Tabelle, hat jede Art von Reproduktion in dem, was Ted als „Satelliten-Datenbank“, kann nicht mit der sehr originell gehalten werden ID, und aus irgendeinem Grund einen neuen erstellen haben, falls Sie die Daten auf dem alten (zum Beispiel aufgrund von Berechtigungen aktualisieren können, oder falls Sie für Echtheit suchen in einem Fall, der ist so kurzlebig, dass verdient es nicht die absolute und völlige Achtung der Gesamt Regeln der Normalisierung, einfach weil wird ein sehr kurzlebig Nutzen sein)

Also, ich stimme in zwei Punkten:

(A.) Ja, in oft ein besseres Design es vermeiden kann; ABER

(B). In Fällen von Migrationen, die Replikation Datenbanken oder Notfälle zu lösen, es ist ein großes Werkzeug, das zum Glück war dabei, als suchte ich ging zu, wenn es existiert.