Sammenfatning af, hvad jeg har set indtil videre:
- Nogle mennesker kan slet ikke lide cascading.
Kaskadeslet
- Cascade Delete kan give mening, når semantikken i forholdet kan involvere en eksklusiv "er en del af " beskrivelse. For eksempel er en OrderLine-post en del af dens overordnede ordre, og OrderLines vil aldrig blive delt mellem flere ordrer. Hvis ordren forsvinder, skulle OrderLine også være det, og en linje uden en ordre ville være et problem.
- Det kanoniske eksempel for Cascade Delete er SomeObject og SomeObjectItems, hvor det ikke giver nogen mening, at en post nogensinde eksisterer uden en tilsvarende hovedpost.
- Du bør ikke brug Cascade Delete, hvis du bevarer historik eller bruger en "blød/logisk sletning", hvor du kun sætter en slettet bitkolonne til 1/sand.
Kaskadeopdatering
- Kaskadeopdatering kan give mening, når du bruger en rigtig nøgle i stedet for en surrogatnøgle (identitet/autoincrement-kolonne) på tværs af tabeller.
- Det kanoniske eksempel på Cascade Update er, når du har en foranderlig fremmednøgle, som et brugernavn, der kan ændres.
- Du bør ikke brug Cascade Update med nøgler, der er identitets-/autoincrement-kolonner.
- Cascade Update bruges bedst sammen med en unik begrænsning.
Hvornår skal man bruge Cascading
- Det kan være en god idé at få en ekstra stærk bekræftelse tilbage fra brugeren, før du tillader, at en operation bryder sammen, men det afhænger af din applikation.
- Cascading kan få dig i problemer, hvis du konfigurerer dine fremmednøgler forkert. Men du burde være okay, hvis du gør det rigtigt.
- Det er ikke klogt at bruge cascading, før du forstår det grundigt. Det er dog en nyttig funktion og derfor værd at tage sig tid til at forstå.