Come funzionano le opzioni 'on update' e 'on delete' della chiave esterna di Postgres?

Question

Qualcuno può fornire una chiara spiegazione / esempio di cosa fanno queste funzioni e quando è appropriato usarle?

Answer 1

Direttamente da il manuale ...

  

Sappiamo che le chiavi esterne non consentono la creazione di ordini che non riguardano alcun prodotto. Ma cosa succede se un prodotto viene rimosso dopo la creazione di un ordine a cui fa riferimento? SQL ti consente anche di gestirlo. Intuitivamente, abbiamo alcune opzioni:

     

Non consentire l'eliminazione di un prodotto referenziato

     

Elimina anche gli ordini

     

Qualcos'altro?

CREATE TABLE order_items (
 product_no integer REFERENCES products ON DELETE RESTRICT,
 order_id integer REFERENCES orders ON DELETE CASCADE,
 quantity integer,
 PRIMARY KEY (product_no, order_id)
);

  

La limitazione e l'eliminazione a cascata sono le due opzioni più comuni. RESTRICT impedisce l'eliminazione di una riga referenziata. NESSUNA AZIONE significa che se esistono ancora righe di riferimento quando viene controllato il vincolo, viene generato un errore; questo è il comportamento predefinito se non si specifica nulla. (La differenza essenziale tra queste due scelte è che NESSUNA AZIONE consente di rinviare il controllo fino a un momento successivo nella transazione, mentre RESTRICT no.) CASCADE specifica che quando una riga referenziata viene eliminata, le righe referenziate dovrebbero essere automaticamente cancellate anche. Esistono altre due opzioni: SET NULL e SET DEFAULT. Questi fanno sì che le colonne di riferimento siano impostate su valori nulli o predefiniti, rispettivamente, quando la riga di riferimento viene eliminata. Nota che questi non ti scusano dall'osservare alcun vincolo. Ad esempio, se un'azione specifica SET DEFAULT ma il valore predefinito non soddisfa la chiave esterna, l'operazione avrà esito negativo.

     

Analogamente a ON DELETE c'è anche ON UPDATE che viene invocato quando una colonna referenziata viene modificata (aggiornata). Le azioni possibili sono le stesse.

modifica: potresti dare un'occhiata a questa domanda correlata: Quando / Perché utilizzare il collegamento in cascata in SQL Server? . I concetti alla base della domanda / risposta sono gli stessi.

Answer 2

Ho un database PostGreSQL e uso su Elimina quando ho un utente che elimino dal database e ho bisogno di eliminare le sue informazioni da un'altra tabella. In questo modo ho bisogno di fare solo 1 cancellazione e FK che ha ON Elimina eliminerà le informazioni dall'altra tabella.

Puoi fare lo stesso con ON Update. Se aggiorni la tabella e il campo ha un FK con On Update, se viene apportata una modifica sull'FK, verrai notato sulla tabella FK.

Answer 3

Ciò che Daok dice è vero ... può essere piuttosto conveniente. D'altra parte, avere cose che accadono automagicamente nel database può essere un vero problema, specialmente quando si tratta di eliminare i dati. È possibile che in futuro qualcuno faccia affidamento sul fatto che gli FK di solito impediscono la cancellazione dei genitori quando ci sono bambini e non si rendono conto che l'uso di On Delete Cascade non solo non impedisce la cancellazione, ma produce enormi quantità di dati in dozzine di altri tavoli scompaiono grazie a una cascata di eliminazioni a cascata.

Il commento di Arthur.

Più frequentemente " nascosto " le cose accadono nel database meno è probabile che qualcuno abbia mai una buona padronanza di ciò che sta accadendo. I trigger (e questo è essenzialmente un trigger) possono causare la mia semplice azione di eliminazione di una riga, con conseguenze di ampio raggio in tutto il mio database. Emetto un'istruzione Delete e 17 tabelle sono interessate da cascate di trigger e vincoli e nulla di tutto ciò è immediatamente evidente all'emittente del comando. OTOH, se inserisco la cancellazione del genitore e di tutti i suoi figli in una procedura, è molto facile e chiaro per chiunque vedere ESATTAMENTE cosa accadrà quando eseguirò il comando.

Non ha assolutamente nulla a che fare con la progettazione di un database. Ha tutto a che fare con i problemi operativi introdotti dai trigger.

Answer 4

Invece di scrivere il metodo per fare tutto il lavoro, dell'eliminazione a cascata o dell'aggiornamento a cascata, puoi semplicemente scrivere un messaggio di avviso. Molto più semplice che reinventare la ruota, e lo rende chiaro al cliente (e ai nuovi sviluppatori che raccolgono il codice)