För det första pratar du om att implementera säkerhet mot idioter som inte skriver projektdokumentation samt idioter som inte läser projektdokumentation. Varför i så fall inte förbjuda delete för att något pucko kan göra delete * from table;. Känner du inte till till 100% hur en databas fungerar SKA du inte jobba med den. PUNKT. Att du som designer tänker på att inte använda funktioner i din RDBMS bara för att du tror att någon i framtiden ska pilla med det som inte är van med funktionen eller inte tänker på att den finns är bara fånigt.

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.

/Zoran

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.

Triggers är kraftfulla och går använda till nästan vadsomhelst, självklart finns det risker med dessa men är man inne och mipplar direkt med sql-queries ska man ha koll på läget.

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 därför InnoDB även stödjer transaktionsloggar :-)

Triggers är väldigt praktiska, MySQL borde även stödja views så skulle man kunna använda triggers mycket mera, då skulle inte vanliga "utvecklare" kunna göra den typen av fel som diskuteras ovan utan bara själva databas-adminstratören.

Att gå in och rota i en databas utan att veta hur den fungerar borde vem somhelst förstå kan straffa sig. Du kör inte bil mot rött heller, eller hur?

Ja du är ju i alla fall ärlig... Men som moderator är väl det ditt jobb? Att läsa allt alltså?

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:
Tänk även på SQL injections...

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.

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.

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.

Jag kör inte mot rött (i din liknelse), men det finns många som gör det. De rotar i databasen utan att veta vad de gör. Triggers är ett exempel på saker man inte bör rota i om man inte verkligen vet vad man gör...

Intressant att du tar upp views. Jag har aldrig sett någon vits med views eftersom allt det man kan göra med views kan göras med sub-selects. Men det är väl precis som triggers (se mitt inlägg ovan där jag pratar om religionskrig) en smaksak. Vi får starta en views tråd också! :D

Rent generellt sett så har ni alla rätt. Puckon ska inte hålla på med databaser och eftersom puckon inte ska göra det så finns inget problem. Det låter dock som om man antingen haft tur eller aldrig jobbat i ett större och/eller projekt med en stor och/eller komplicerad databasmodell. Som jag skrev tidigare så är de flesta webplatser inte speciellt upphetsande ur DB-designssynvinkel och det kan vara en förklaring. Men på samma sätt som jag inte kör mot rött - på samma sätt är världen full av människor som kör fulla. Jag kan aldrig skydda mig till 100%, men jag kan minimera riskerna och jag kan försöka få de som kör fulla att sluta med det (om vi skall dra liknelsen till sin spets).

Oh man!

Får känslan att egomaster har läst på massor om dessa triggers, kanske till och med råkat använda dem till att ta bort något och då råkat ta bort massa andra saker som det inte var tänkt från början. En händelse som skulle kunna resultera i att han läser tokmycket mer om triggers för att sedan få sig en uppfattning om vad man bör använda dem till och vad man absolut inte bör använda dem till.

Till råga på allt verkar det finnas intresse att "läxa upp" alla som inte använder dem till samma sak som han själv, får det intrycket. Inläggen är lite överlägset skrivna och han ser ner på alla som använder dem på detta farliga, förbjudna sätt...

Han orkade dock inte säga vad trigger var för något, tack Thomas för att du orkade kolla upp det. Det i sig gjorde att jag läste runt 15 inlägg till om dessa triggers utan att bli desto klokare eller gladare.

egomaster däremot verkar ha fått skriva av sig och visa sina triggerkunskaper genom att själva starta tråden med ett provocerande argument som någon nappade på. Det här blev ännu ett värdelöst inlägg men efter att ha läst om dessa f-b triggers i 10 minuter så behövde jag skriva av mig då jag blev väldigt less mot slutet, då tråden i sig inte gav desto mer utan mest kändes som nån bisarr form av skryt. :(

Okej, dina erfarenheter har kanske präglat din syn på hur utveckling ska gå till, det förstår jag. Jag personligen tar ansvar för mig själv och räknar att andra ska göra likaså. När jag får ett verktyg i handen som kan göra "foo, bar, gazonk" tänker inte jag bara använda "foo, bar" just för att det känns som att "gazonk" inte är så vanlig. Har jag designat min databas bra från början och jag har satt en trigger som SKA ta bort data som inte behövs, så har jag sett till att den tar bort data endast när den inte behövs. Det är ju det man har testfas till. Beter sig den som den ska under olika former så vet jag att min produkt fungerar. Sen dokumenteras det hela.

Om nu någon släpps till till databasen som ändå på något sätt lyckas ställa till med förödelse, är det lika lite mitt fel som om någon skulle logga in på burken och köra rm -fr / som root. Med andra ord, man kan inte anse sig vara barnflicka åt alla sina projekt man har deltagit i.

En annan sak, tror du att den personen som inte orkade läsa din väldokumenterade databas, orkar läsa genom 500 rader perlkod och förstå vad som händer? Perl som är såååå lättläsligt. Knappast.

Du har ju kunskap om hur din omgivning fungerar. Är det så att det är som du säger, så skulle jag personligen vilja ändra det, upplysa dem, eller liknande.

/Zoran

Nja, jag tror egomaster vet nog vad han pratar om. Hans argument är inte tagna ur luften och verkar vara hans egna. Jag hyser respekt för hans kompetens men jag håller inte med honom när det gäller triggersämnet. Att han lägger snacket på så hög nivå beror snarare på ämnet än att någon av deltagarna vill "showa off". Triggers är ju inte det första man lär sig när man håller på med databaser och har tämligen smalt användningsområde.

Han "läxar inte upp oss" mer än vad vi försöker läxa upp honom. Ungefär som vanligt här.

/Zoran

För att vara lite offtopic, views är minst lika användbara som triggers i en fleranvändarmiljö..

Om du driver ett större projekt där tex en eller flera utvecklare skall utveckla en del av ett system finns det igentligen ingen anledning till att de skall ha fullständiga rättigheter till hela databasen. Eller ens hela tabeller.

Ponera att du tex outsourcar jobb med din ehandelssite till utomstående konsulter, då kanske du inte vill ge dem tillgång till dina kunders visakortnummer. Enkelt löst med views.
Sure, du kan väl skriva nån slags wrapped med subselects, men då kan du juh inte ge utvecklarna direkt åtkomst till databasen.

Varför alla sura miner föresten? Det är väl inte egomasters eller nån annans fel att ni inte vet vad triggers är? Det är en teknisk pryl i databaser. Jag biter mig i tungan varje dag när jag läser era idiotiska diskussioner om domännamn ni försöker kränga för trettiofem fantasiljoner.