Podsumowanie tego, co do tej pory widziałem:
- Niektórzy w ogóle nie lubią kaskad.
Usuń kaskadowo
- Usuwanie kaskadowe może mieć sens, gdy semantyka relacji może obejmować wyłączną „jest częścią opis. Na przykład rekord OrderLine jest częścią swojego zamówienia nadrzędnego, a OrderLines nigdy nie będą współdzielone między wieloma zamówieniami. Jeśli zamówienie zniknie, OrderLine również powinno, a linia bez zamówienia byłaby problemem.
- Kanoniczny przykład Cascade Delete to SomeObject i SomeObjectItems, gdzie nie ma sensu, aby rekord pozycji kiedykolwiek istniał bez odpowiedniego rekordu głównego.
- Nie powinieneśnie użyj kasowania kaskadowego, jeśli zachowujesz historię lub używasz „miękkiego/logicznego usuwania”, w którym ustawiasz tylko kolumnę usuniętych bitów na 1/prawda.
Aktualizacja kaskadowa
- Aktualizacja kaskadowa może mieć sens, gdy używasz prawdziwego klucza zamiast klucza zastępczego (kolumna tożsamości/autoinkrementacji) w różnych tabelach.
- Kanoniczny przykład aktualizacji kaskadowej to sytuacja, w której istnieje zmienny klucz obcy, taki jak nazwa użytkownika, którą można zmienić.
- Nie powinieneśnie użyj aktualizacji kaskadowej z kluczami, które są kolumnami tożsamości/autoinkrementacji.
- Aktualizacji kaskadowej najlepiej używać w połączeniu z unikalnym ograniczeniem.
Kiedy używać kaskadowania
- Możesz chcieć uzyskać bardzo silne potwierdzenie od użytkownika przed zezwoleniem na kaskadowanie operacji, ale zależy to od Twojej aplikacji.
- Kaskadowanie może wpędzić Cię w kłopoty, jeśli źle skonfigurujesz klucze obce. Ale powinieneś być w porządku, jeśli zrobisz to dobrze.
- Nie jest mądrze używać kaskadowania, zanim dokładnie je zrozumiesz. Jest to jednak przydatna funkcja i dlatego warto poświęcić czas na zrozumienie.
