Quando utilizzare "ON AGGIORNAMENTO CASCADE"

Uso regolarmente "ON DELETE CASCADE", ma non utilizzo mai "ON UPDATE CASCADE" in quanto non sono così sicuro in quale situazione sarà utile.

Per motivi di discussione, vediamo un po 'di codice.

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
);

Per "ON DELETE CASCADE", se un genitore con un idviene eliminato, un record nel figlio con parent_id = parent.idverrà automaticamente eliminato. Questo non dovrebbe essere un problema.

1. Ciò significa che "IN AGGIORNAMENTO CASCADE" farà la stessa cosa quando idil genitore viene aggiornato?

2. Se (1) è vero, significa che non è necessario utilizzare "AGGIORNAMENTO CASCADE" se parent.idnon è aggiornabile (o non verrà mai aggiornato) come quando è AUTO_INCREMENTo è sempre impostato TIMESTAMP. È giusto?

3. Se (2) non è vero, in quale altro tipo di situazione dovremmo usare "AGGIORNAMENTO CASCADE"?

4. Che cosa succede se (per qualche motivo) aggiorno child.parent_idper essere qualcosa che non esiste, verrà automaticamente cancellato?

Bene, lo so, alcune delle domande precedenti possono essere testate a livello di codice per capire, ma voglio anche sapere se qualcuno di questi dipende dal fornitore del database o meno.

Per favore, fai luce.

È vero che se la tua chiave primaria è solo un valore di identità auto incrementato, non avresti alcun reale utilizzo per ON UPDATE CASCADE.

Tuttavia, supponiamo che la chiave primaria sia un codice a barre UPC a 10 cifre e, a causa dell'espansione, è necessario modificarlo in un codice a barre UPC a 13 cifre. In tal caso, ON UPDATE CASCADE consentirebbe di modificare il valore della chiave primaria e qualsiasi tabella che abbia riferimenti di chiave esterna al valore verrà modificata di conseguenza.

In riferimento a # 4, se si modifica l'ID figlio in qualcosa che non esiste nella tabella padre (e si dispone di integrità referenziale), si dovrebbe ottenere un errore di chiave esterna.

1. Sì, significa che, ad esempio, se fai UPDATE parent SET id = 20 WHERE id = 10tutti i figli parent_id di 10 verrà aggiornato anche a 20

2. Se non si aggiorna il campo a cui fa riferimento la chiave esterna, questa impostazione non è necessaria

3. Non riesco a pensare a nessun altro uso.

4. Non è possibile farlo poiché il vincolo di chiave esterna fallirebbe.

Penso che tu abbia praticamente inchiodato i punti!

Se segui le migliori pratiche di progettazione del database e la tua chiave primaria non è mai aggiornabile (cosa che penso dovrebbe essere sempre il caso), allora non hai mai davvero bisogno del ON UPDATE CASCADE clausola.

Zed ha sottolineato che se usi un naturale chiave (ad esempio un campo normale dalla tabella del database) come chiave primaria, potrebbero esserci determinate situazioni in cui è necessario aggiornare le chiavi primarie. Un altro esempio recente potrebbe essere il codice ISBN (International Standard Book Numbers) che è cambiato da 10 a 13 cifre + caratteri non molto tempo fa.

Questo non è il caso se si sceglie di utilizzare surrogato chiavi (ad es. Generate artificialmente dal sistema) come chiave primaria (che sarebbe la mia scelta preferita in tutte le occasioni tranne le più rare).

Quindi alla fine: se la tua chiave primaria non cambia mai, allora non hai mai bisogno della ON UPDATE CASCADEclausola.

Marc

Qualche giorno fa ho avuto un problema con i trigger e ho capito che ON UPDATE CASCADEpuò essere utile. Dai un'occhiata a questo esempio (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
);

Nel mio problema, ho dovuto definire alcune operazioni aggiuntive (trigger) per l'aggiornamento del tavolo del concerto. Tali operazioni hanno dovuto modificare club_name e band_name. Non sono riuscito a farlo, a causa del riferimento. Non ho potuto modificare il concerto e poi occuparmi dei tavoli di club e band. Non potrei farlo anche nell'altro modo. ON UPDATE CASCADEè stata la chiave per risolvere il problema.

Il mio commento è principalmente in riferimento al punto 3: in quali circostanze è applicabile AGGIORNAMENTO CASCADE se assumiamo che la chiave padre non sia aggiornabile? Ecco un caso.

Ho a che fare con uno scenario di replica in cui più database satellitari devono essere uniti a un master. Ogni satellite sta generando dati sulle stesse tabelle, quindi l'unione delle tabelle con il master porta a violazioni del vincolo di unicità. Sto provando a utilizzare ON UPDATE CASCADE come parte di una soluzione in cui incremento nuovamente le chiavi durante ogni unione. IN AGGIORNAMENTO CASCADE dovrebbe semplificare questo processo automatizzando parte del processo.

È un'ottima domanda, ho avuto la stessa domanda ieri. Ho pensato a questo problema, in particolare RICERCA se esistesse qualcosa come "IN AGGIORNAMENTO CASCADE" e per fortuna anche i progettisti di SQL ci avevano pensato. Sono d'accordo con Ted.strauss e ho anche commentato il caso di Noran.

Quando l'ho usato? Come ha sottolineato Ted, quando si trattano più database contemporaneamente e la modifica in uno di essi, in una tabella, ha qualsiasi tipo di riproduzione in quello che Ted chiama "database satellite", non può essere mantenuta con l'originale ID e per qualsiasi motivo devi crearne uno nuovo, nel caso in cui non sia possibile aggiornare i dati su quello vecchio (ad esempio a causa di autorizzazioni o nel caso in cui tu stia cercando solidità in un caso così effimero che non merita il rispetto assoluto e assoluto per le regole totali di normalizzazione, semplicemente perché sarà un'utilità di breve durata)

Quindi, sono d'accordo in due punti:

(A.) Sì, molte volte un design migliore può evitarlo; MA

(B.) In caso di migrazioni, replica di database o risoluzione di emergenze, è UN GRANDE STRUMENTO che fortunatamente era lì quando sono andato a cercare se esistesse.