Sammanfattning av vad jag har sett hittills:
- Vissa människor gillar inte överlappande alls.
Ta bort kaskad
- Cascade Delete kan vara vettigt när semantiken i relationen kan involvera en exklusiv "är en del av " beskrivning. Till exempel är en OrderLine-post en del av dess överordnade order, och OrderLines kommer aldrig att delas mellan flera order. Om Ordern skulle försvinna bör OrderLine också, och en rad utan Order skulle vara ett problem.
- Det kanoniska exemplet för Cascade Delete är SomeObject och SomeObjectItems, där det inte är meningsfullt att en objektpost någonsin existerar utan en motsvarande huvudpost.
- Du borde inte använd Cascade Delete om du bevarar historik eller använder en "mjuk/logisk radering" där du bara ställer in en raderad bitkolumn till 1/true.
Kaskaduppdatering
- Cascade Update kan vara vettigt när du använder en riktig nyckel snarare än en surrogatnyckel (identitet/autoinkrement-kolumn) över tabeller.
- Det kanoniska exemplet för Cascade Update är när du har en föränderlig främmande nyckel, som ett användarnamn som kan ändras.
- Du borde inte använd Cascade Update med nycklar som är identitets-/autoinkrement-kolumner.
- Cascade Update används bäst tillsammans med en unik begränsning.
När ska man använda Cascading
- Du kanske vill få en extra stark bekräftelse tillbaka från användaren innan du tillåter en operation att överlappa, men det beror på din applikation.
- Cascading kan få dig till problem om du ställer in dina främmande nycklar fel. Men du borde klara dig om du gör det rätt.
- Det är inte klokt att använda cascading innan du förstår det ordentligt. Det är dock en användbar funktion och därför värd att ta sig tid att förstå.