Kiedy używać " na kaskadzie aktualizacji"

1. Tak, oznacza to, że na przykład, jeśli wykonasz UPDATE parent SET id = 20 WHERE id = 10 wszystkie dzieci parent_id z 10 zostaną również zaktualizowane do 20

2. Jeśli nie zaktualizujesz pola, do którego odnosi się klucz obcy, to ustawienie nie jest potrzebne

3. Nie mogę wymyślić innego zastosowania.

4. Nie możesz tego zrobić, ponieważ ograniczenie klucza obcego zawiedzie.

Myślę, że prawie trafiłeś w sedno!

Jeśli stosujesz najlepsze praktyki projektowania baz danych i twój klucz podstawowy nigdy nie jest aktualizowalny( co I tak powinno być zawsze), to nigdy tak naprawdę nie potrzebujesz klauzuli ON UPDATE CASCADE.

Zed dobrze zauważył, że jeśli użyjesz klucza natural (np. zwykłego pola z tabeli bazy danych) jako klucza podstawowego, to mogą wystąpić sytuacje, w których będziesz musiał zaktualizować klucze podstawowe. Kolejne Ostatnie przykładem może być ISBN (International Standard Book Numbers), który zmienił się z 10 do 13 cyfr+znaków nie tak dawno temu.

Tak nie jest, jeśli zdecydujesz się użyć zastępczych (np. sztucznie generowanych systemowo) kluczy jako klucza podstawowego(co byłoby moim preferowanym wyborem we wszystkich, ale najbardziej rzadkich przypadkach).

Więc na koniec: jeśli twój klucz podstawowy nigdy się nie zmienia, to nigdy nie potrzebujesz klauzuli ON UPDATE CASCADE.

Marc

Kilka dni temu miałem problem z wyzwalaczami i odkryłem, że ON UPDATE CASCADE mogą być przydatne. Spójrz na ten przykład (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
);

W moim numerze musiałem zdefiniować kilka dodatkowych operacji (trigger) do aktualizacji tabeli koncertowej. Te operacje musiały zmodyfikować nazwę klubu i nazwę zespołu. Nie byłem w stanie tego zrobić, z powodu referencji. Nie mogłem zmodyfikować koncertu, a potem zająć się klubowymi i zespołowymi stolikami. Nie mogłem też zrobić tego w drugą stronę. ON UPDATE CASCADE był kluczem do rozwiązania problemu.

Mój komentarz jest głównie w odniesieniu do punktu # 3: w jakich okolicznościach ma zastosowanie kaskada aktualizacji, jeśli Zakładamy, że klucz rodzica nie jest aktualizowalny? Oto jedna sprawa.

Mam do czynienia ze scenariuszem replikacji, w którym wiele satelitarnych baz danych musi być połączonych z master. Każdy Satelita generuje dane na tych samych tabelach, więc łączenie tabel z master prowadzi do naruszenia ograniczenia unikalności. Próbuję użyć na UPDATE CASCADE jako część rozwiązanie, w którym ponownie zwiększam klucze podczas każdego scalania. Kaskada aktualizacji powinna uprościć ten proces, automatyzując część procesu.

To doskonałe pytanie, miałem to samo pytanie wczoraj. Myślałem o tym problemie, specjalnie szukał, czy istnieje coś takiego jak "na kaskadzie aktualizacji" i na szczęście projektanci SQL również myślał o tym. Zgadzam się z Tedem.Straussa, a także skomentowałem sprawę Norana.

Kiedy go użyłem? Jak zauważył Ted, kiedy traktujesz kilka baz danych naraz, a modyfikacja w jednej z nich, w jednej tabeli, ma jakikolwiek rodzaj reprodukcji w tym, co nazywa Ted "satellite database", nie może być przechowywana z bardzo oryginalnym identyfikatorem i z jakiegokolwiek powodu musisz utworzyć nowy, w przypadku, gdy nie możesz zaktualizować danych na starym (na przykład ze względu na uprawnienia, lub w przypadku, gdy szukasz trwałości W przypadku, który jest tak efemeryczny, że nie zasługuje na absolutny i całkowity szacunek dla całkowitych zasad normalizacji, po prostu dlatego, że będzie bardzo krótkotrwałe Narzędzie)

Więc zgadzam się w dwóch punktach:

(A.) Tak, w wielu przypadkach lepszy projekt można tego uniknąć; ale

(B.) W przypadku migracji, replikacji baz danych lub rozwiązywania sytuacji awaryjnych, jest to świetne narzędzie, które na szczęście było tam, kiedy poszedłem szukać, czy istnieje.