Citat:
|
Jag orkade inte läsa det sista inlägget...
|
Ja du är ju i alla fall ärlig... Men som moderator är väl det ditt jobb? Att läsa allt alltså?
Citat:
|
Men det är en poäng till jag skulle vilja göra. Om du tar bort en post ur en tabell som har en primärnyckel som är referensnyckel i en annan tabell så är alla poster i den andra tabellen som pekar på den borttagna posten helt meningslösa. De posterna ligger sålunda i den andra tabellen och skräpar. Eftersom du inte har dess master så är alla detail:er i master-detail-förhållandet data helt utan betydelse och kan (snarare SKA) tas bort.
|
Poängen du missade i det långa inlägget var just att genom att inte automatiskt ta bort saker får programmeraren en feedback på vad som skall ta bort. Lär i alla fall detta från mitt betydligt kortare inlägg:
Citat:
|
Och du missar den viktigaste poängen av alla. Risken att radera fel data för att du är slarvig med ditt villkor till en delete borde vara skäl nog för att inte använda triggers eller cascading deletes.
|
Tänk även på SQL injections...
Citat:
|
Dokumentera vad du gör i din databas och hur den ser ut. Sen får framtida utvecklare skylla sig själva ifall de inte läser dokumentationen och sätter i gång att pilla med den. För att inte tala om att man ska ta backup på hela skiten.
|
Ja jag pratar om att skydda mig från idioter som knappt vet vad de gör och som inte läser dokumentation. Men välkommen till verkligheten. Omgivningen är full av idioter :-) Men handen på hjärtat; Hur många lusläser dokumentation? Och hur många tar backup innan varje SQL sats de kör? Backuper ibland gör skadan mindre, men inte minimal.
Citat:
För det första bör vi nog skilja på triggers och cascading deletes/updates (foreign keys).
Jag skulle snarare säga att det omvända gäller när vi talar om cascading deletes, använder man inte foreign keys finns det stora risker att databasen innehåller ofullständig data/referenser. Anta att någon går in och byter användar-ID på två användare(kanske inte så vanligt). Utan foreign keys måste den som ändrar ha full koll på att också uppdatera övriga tabeller.
|
Ja triggers & cascading deletes är 2 mycket skilda saker. Men det finns inget likhetstecken mellan cascading deletes och foreign keys!
Självklart skall man i databasen ha foreign keys, constraints och t.o.m. triggers för att garantera att data i databasen inte blir ofullständig. Men att radera ALLT som är beroende av en tabell
kan vara farligt. Det jag försöker få fram är alltså att visst är det bekvämt med en cascading delete, men man måste väge bekvämligheten mot risken att av misstag radera hela databasen pga ett felaktigt villkor.
Citat:
|
Själv så hatar jag personer som lägger väldigt mycket bussiness logic i sp's, men det är en annan femma.
|
Det är en annan femma och en gång i tiden såg jag mest fördelar med detta, men på den punkten har jag ändrat åsikt... :unsure:
Reflektion:
Jag kan förstå vilka fördelar man vill uppnå med en trigger (eller cascading delete) och även om jag tycker framförallt triggers (men även cascading deletes) till stor del döljer viktig funktionalitet (när man läser koden och ser "delete person where id=1" tänker man i kanske "jaha resten är väl raderat ngn annan stans). Men ok. Vi dokumenterar detta med en kommentar också. Då skulle jag nog välja medelvägen; Låt triggern (cascading delete) ta bort alla beroende poster,
men låt även triggern generera ett fel om man försöker ta bort mer än en rad i varje delete. På så sätt "slipper" jag skriva en massa kod samtidigt som jag skyddar mig mot puckon och sql injection.
INGEN är perfekt.