Używam „ON DELETE CASCADE” regularnie, ale nigdy nie używam „ON UPDATE CASCADE”, ponieważ nie jestem pewien, w jakiej sytuacji będzie to przydatne.
Dla celów dyskusji zobaczmy trochę kodu.
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
);
W przypadku „PRZY USUWANIU KASKADY”, jeśli rodzic nadrzędny z id
zostanie usunięty, zapis podrzędny z parent_id = parent.id
zostanie automatycznie usunięty. To nie powinno być problemu.
Oznacza to, że „ON UPDATE CASCADE” zrobi to samo, gdy
id
rodzic zostanie zaktualizowany?Jeśli (1) jest prawdą, oznacza to, że nie ma potrzeby używania opcji „ON UPDATE CASCADE”, jeśli
parent.id
nie można jej aktualizować (lub nigdy nie będzie aktualizowana), tak jak ma to miejsceAUTO_INCREMENT
lub zawsze jest ustawioneTIMESTAMP
. Czy to prawda?Jeśli (2) nie jest prawdziwe, w jakiej innej sytuacji powinniśmy użyć „ON UPDATE CASCADE”?
Co się stanie, jeśli (z jakiegoś powodu) zaktualizuję
child.parent_id
coś, co nie istnieje, czy zostanie to automatycznie usunięte?
Cóż, wiem, niektóre z powyższych pytań można przetestować programowo, aby je zrozumieć, ale chcę również wiedzieć, czy którekolwiek z nich jest zależne od dostawcy bazy danych.
Proszę rzucić trochę światła.
Odpowiedzi:
Prawdą jest, że jeśli twój klucz podstawowy jest tylko automatycznie zwiększaną wartością tożsamości, nie miałbyś prawdziwego zastosowania do ON UPDATE CASCADE.
Załóżmy jednak, że kluczem podstawowym jest 10-cyfrowy kod kreskowy UPC, a ze względu na rozszerzenie musisz go zmienić na 13-cyfrowy kod kreskowy UPC. W takim przypadku NA AKTUALIZACJI KASKADA umożliwi zmianę wartości klucza podstawowego, a wszelkie tabele zawierające odwołania do klucza obcego do tej wartości zostaną odpowiednio zmienione.
W odniesieniu do # 4, jeśli zmienisz identyfikator podrzędny na coś, co nie istnieje w tabeli nadrzędnej (i masz integralność referencyjną), powinieneś otrzymać błąd klucza obcego.
źródło
ON UPDATE CASCADE
siebie, aby zaktualizować klucze podstawowe w starej tabeli, która nie korzysta z klucza automatycznie zwiększanegoTak, oznacza to, że na przykład, jeśli zrobisz
UPDATE parent SET id = 20 WHERE id = 10
wszystkie dzieci, Parent_id's z 10 również zostanie zaktualizowany do 20Jeśli nie zaktualizujesz pola, do którego odnosi się klucz obcy, to ustawienie nie jest potrzebne
Nie mogę wymyślić żadnego innego zastosowania.
Nie możesz tego zrobić, ponieważ ograniczenie klucza obcego zawiódłoby.
źródło
Myślę, że prawie nabiłeś punktów!
Jeśli postępujesz zgodnie z najlepszymi praktykami dotyczącymi projektowania baz danych, a klucz podstawowy nigdy nie jest aktualizowalny (co moim zdaniem powinno zawsze tak być), to tak naprawdę nigdy nie potrzebujesz
ON UPDATE CASCADE
klauzuli.Zed miał rację , że jeśli użyjesz klucza naturalnego (np. Zwykłego pola z tabeli bazy danych) jako klucza podstawowego, mogą zaistnieć sytuacje, w których musisz zaktualizować klucze podstawowe. Innym niedawnym przykładem byłby ISBN (Międzynarodowe Standardowe Numery Książek), który nie tak dawno zmienił się z 10 na 13 cyfr + znaków.
Nie dzieje się tak, jeśli zdecydujesz się użyć kluczy zastępczych (np. Sztucznie wygenerowanych przez system) jako klucza podstawowego (który byłby moim preferowanym wyborem we wszystkich, oprócz najrzadszych).
Na koniec: jeśli twój klucz podstawowy nigdy się nie zmienia, to nigdy nie potrzebujesz
ON UPDATE CASCADE
klauzuli.Marc
źródło
colors
z wierszyblue
,purple
,yellow
oraz stółproducts
zproduct_color
kolumny jest FK'ed docolors
tabeli. Ogranicza to opcje jak wyliczanie, ale w przeciwieństwie do liczby całkowitej z auto-inkrementacją nie wymaga łączenia, aby uzyskać nazwę koloru. W takim przypadkuon update cascade
jest dobrym pomysłem, jeśli zdecydujesz, że zamiast tegopurple
należy zadzwonićviolet
.Kilka dni temu miałem problem z wyzwalaczami i doszedłem do wniosku, że
ON UPDATE CASCADE
może to być przydatne. Spójrz na ten przykład (PostgreSQL):W moim wydaniu musiałem zdefiniować dodatkowe operacje (wyzwalacz) do aktualizacji tabeli koncertu. Operacje te musiały zmodyfikować nazwę klubu i nazwę zespołu. Nie mogłem tego zrobić z powodu odniesienia. Nie mogłem modyfikować koncertu, a następnie radzić sobie ze stołami klubowymi i zespołowymi. Nie mógłbym tego zrobić również w drugą stronę.
ON UPDATE CASCADE
był kluczem do rozwiązania problemu.źródło
SERIAL
kolumnclub
iband
jako kluczy pierwotnych, jeśli odwołaćname
S zamiast klucza podstawowego każdego stołu?Mój komentarz odnosi się głównie do punktu 3: w jakich okolicznościach NA ZAKTUALIZOWANIU KASKADA ma zastosowanie, jeśli zakładamy, że klucz nadrzędny nie jest aktualizowany? Oto jeden przypadek.
Mam do czynienia ze scenariuszem replikacji, w którym wiele satelitarnych baz danych należy połączyć z masterem. Każdy satelita generuje dane na tych samych tabelach, więc scalenie tabel z modułem głównym prowadzi do naruszenia ograniczenia wyjątkowości. Próbuję użyć ON UPDATE CASCADE jako części rozwiązania, w którym ponownie zwiększam klucze podczas każdego scalania. PRZY AKTUALIZACJI KASKADA powinna uprościć ten proces, automatyzując jego część.
źródło
To doskonałe pytanie, miałem to samo pytanie wczoraj. Myślałem o tym problemie, w szczególności WYSZUKIWANIU, jeśli istniało coś takiego jak „ON UPDATE CASCADE” i na szczęście projektanci SQL również o tym pomyśleli. Zgadzam się z Ted.strauss, a także skomentowałem sprawę Norana.
Kiedy go użyłem? Jak wskazał Ted, kiedy traktujesz kilka baz danych jednocześnie, a modyfikacja jednej z nich, w jednej tabeli, ma jakiekolwiek reprodukcje w czymś, co Ted nazywa „satelitarną bazą danych”, nie może być przechowywane z bardzo oryginalnym Identyfikator i z jakiegokolwiek powodu musisz utworzyć nowy, na wypadek, gdybyś nie mógł zaktualizować danych na starym (na przykład ze względu na uprawnienia lub jeśli szukasz szybkości w sprawie, która jest tak efemeryczna, że nie zasługuje na absolutny i całkowity szacunek dla ogólnych zasad normalizacji, po prostu dlatego, że będzie to bardzo krótkotrwała użyteczność)
Zgadzam się więc w dwóch punktach:
(A.) Tak, w wielu przypadkach lepszy projekt może tego uniknąć; ALE
(B.) W przypadku migracji, replikacji baz danych lub rozwiązywania sytuacji awaryjnych jest to WIELKIE NARZĘDZIE, które na szczęście było tam, kiedy szukałem, czy istnieje.
źródło