Med anledning av en annan tråd som ger mig kalla kårar... Varför? Jo jag får känslan att det finns personer som tycker triggers är bra och en tillgång.
Det finns enstaka fall där triggers är "bra", men jag vill gärna veta vad andra tycker. Eftersom triggers ofta missbrukas vill jag gärna veta hur ni andra tänkt (eller redan använder) triggers så kan vi föra en diskussion därifrån...

Vad i hela världen? Du VET vad en trigger är eller? :lol: :lol:

Jag får väl rösta för att triggers är det bästa som finns helt enkelt. För närvarande, när jag tar bort en användare från min sajt, kör jag ett Perl-skript på fem hundra rader. Det tar bort användaren, alla dikter han skrivit, alla kommentarer som lagts på den dikten och så vidare och så vidare. Tar en mindre evighet alltså. Om jag hade kunnat använda ON DELETE CASCADE eller en trigger för att rensa så hade jag bara kunnat göra DELETE FROM users WHERE ID = x och så hade det varit klart.

okey jag fick söka, nu slipper ni som inte vet vad en trigger är det i alla fall, det är nån sql grej.

Trigger is a Concept from RDBMS like Oracle & SQL Server
There we can write functions which are invoked as soon as a
DML (insert/update/delete) operation is performed on a database table.

Thomas

Jag är mer nyfiken på var du anser är att "ofta missbruka triggers".

Personligen använder jag triggers i Sybase. Eftersom Sybase sparar sina transaktionsloggar på en separat device, kan det hända att den blir full. För databaser som inte är speciellt viktiga (exempelvis för "lek") använder jag triggers att göra en dump tran with truncate_only, mao att kasta bort transaktionsloggen så fort den blir full. Annan tillämpning är att automatiskt göra backup på band av transaktionsloggen som blir full eller att låta Sybase skicka iväg ett mail med varningen.

/Zoran

Hehe... ok då kör vi...

Att använda sig av cascading deletes elelr att rensa saker i tabell B pga att en trigger körs pga en händelse i tabell A är ont. Varför? Jo för att när någon annan ska använda datatabasen än den som ursprungligen designade den eller upphovsmannen helt enkelt är glömsk så blir det en överraskning att en delete i persontabellen även resulterade i att massor av annat data deletas också. Det finns även en säkerhetsaspekt här. Vi fortsätter med delete exemplet: Om du av misstag råkar göra "delete from person where 1=1" så raderas i princip allt data ur din databas. Om du istället manuellt (500 rader perl verkar omständigt om det inte är 500 olika tabeller det skall raderas i) raderar det som är beroende av person så riskerar du inte att radera för mycket. Dessutom ser du (och någon annan som jobbar med databasen) vilka beroende som finns.
Exempel: Jag ska hjälpa dig och implementera en funktion som tar bort alla artiklar en person skrivit. Jag gör delete på tabellen och då visar det sig att det fanns ett beroende till en favoriter. Nu vet jag eftersom deleten misslyckades att kommentarer också måste raderas och det kanske vi inte vill (för personer som markerat en artikel som favorit kanske måste godkänna att den raderas).

Det är på detta sätt triggers ofta missbrukas. Man är för lat att göra saker i sin applikation i rätt ordning och på så sätt får operationer oväntade beteenden (för det är oväntat att en delete i en tabell genererar delete i en massa andra tabeller).

Så när (i min mening) är triggers bra?
Ja, exemplet med sybase där man gör systemunderhåll ligger väl i gränslandet (varför inte en schemalagd händelse som rensar istället).

Själv använder jag bara triggers för att skydda mina databaser mot utvecklare som skriver felaktig kod.
Exempel: En trigger som förhindrar att mer än en person raderas åt gången. Eller en trigger som förhindrar att en skickad faktura raderas ur databasen osv.
Alla saker som triggern kollar skall kollas i applikationen, men om det finns en bug i logiken är triggern sista utposten som förhindrar att en felaktig operation på just den tabellen görs. En trigger bör (enligt alla databasmänniskor jag känner) aldrig ändra data. bara kontrollera data och eventuellt generera ett fel och en rollback.

Galenskap! Jag tänker inte diskutera nåt så surrealistiskt som att triggers skulle vara ONDA för att man använder dem till vad de är till för... Men i mitt fall så är att ta bort ALLT som har med en användare att göra PRECIS vad jag vill göra så ON DELETE CASCADE är PRECIS vad jag vill ha.

Jag tvivlar inte en sekund på att det är det du vill göra. Frågan är vad resultatet blir när någon annan ska skriva något till samma databas.

Och vem säger att triggers är till för att just ändra data? Är inte det kanske bara en otäck sidoeffekt att det finns den möjligheten?

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.

Hur skulle triggers kunna vara onda när de ger en funktionalitet som är väldigt smidig och tidsbesparande? Det allra mesta går att använda felaktigt och dumt, det förminskar inte nyttan i korrekt användande. De allra flesta slutanvändare av databasapplikationer gör aldrig en direkt fråga mot databasen, så klumpiga sådana är sällan en anledning att anpassa databasendesignen på något sätt.

När MySQL 5.0.2+ blir välanvänd kommer man säkerligen se en uppsjö av dumma och klumpiga användanden av triggers, men för utvecklaren som vet vad han gör är det självklart en väldigt bra sak.

Triggers tidsbesparande?
Ja i ett initialt läge kanske? Men i längden leder det ofta till missförstånd av hur saker görs och/eller försvårar debugging av databasfrågor eftersom det inte tydligt framgår vad som görs när. Dessutom är ju triggers lite klurigare att steppa igenom kanske...

Nej slutanvändare ska inte ha något i databasen att göra! Det är nästan så jag blir förolämpad för att du tror att jag tror det...

Du talar om utvecklaren, dvs i singularis. Det må stämma i mindre projekt men så snart man är mer än en så lutar det nog åt att en person gör DB design och en annan koncentrerar sig på annat. Och även om man är själv så har man båda dessa roller att jobba i.
Att sedan tro att en utvecklare (om det nu är du själv i "utvecklar rollen" eller om det är någon annan) inte kommer göra fel och i något läge misstolka hur databasen är tänkt att fungera så har du antingen en osannolik tur (och borde köpa en lott) eller så är DB designen så enkel att den inte går att feltolka.

Det är ju just detta jag jagar efter. Hur använder man triggers på ett bra sätt? Vad bör utvecklaren tänka på?

Nu vet jag att databasen för en typisk webapplikation är betydligt enklare än många av de databaser jag jobbat med i mina dagar, men det har egentligen inte med saken att göra eftersom en webapplikation mycket väl kan bli ganska avancerad med tiden.

Triggers är ett lika hett ämne som windows vs linux eller vilken rad "{" skall vara på i en if-sats i ett C-program. Och det är intressant att se hur detta religionskrig (om jag får kalla det det) visar att jag blir lika missförstådd och till viss del idiotförklarad på samma sätt som jag själv dömer de som inte sett "det onda" med triggers som databas-amatörer.

Man må kalla det fördomsfullt, men av alla inlägg om SQL och databaser så får jag hela tiden en kännsla av att frågorna i stor utsträckning uppkommer för att allt för många kastar sig in i "databasträsket" och gör en modell utan att för den delen varken ha erfarenhet eller kunskap om hur de borde göra. Visst, många av er har säkert ärvt ett system designat av en amatör, men det känns som om det finns ytterst få DB-modeller som faktiskt är riktigt bra när man kikar på web-applikationer.

Detta kan ha flera orsaker. Dels står amatörerna för sin del, men även en websidas föränderlighet bidrar. Det tar tid att bli bra på att göra DB-modeller och det kräver framförallt extremt goda kunskaper om problemdomänen och även fantasi för att förutse ev förändringar och anpassningskrav.

Syftet med den här tråden var att förhoppningsvis rädda några personer från att göra misstaget att använda triggers "för med de kan man göra en massa bra saker utan att skriva kod i sitt program" samtidigt som jag ville utmana mig själv och se om det finns någon som faktiskt använder triggers på ett vettigt sätt. Som jag själv skrev tidigare finns det några fall som känns motiverade och de flesta deltagarna i detta "krig" är betydligt mer "svart eller vitt"-seende än vad jag är.

Förhoppningsvis kommer någon som läser detta inte bara nicka instämmande eller fnysa nedlåtande och sedan gå vidare utan någon som läser detta komemr "tänka efter före" och då blir jag nöjd för då har jag bidragit till bättre kvallité. Många tycker nog jag är pervers på den punkten, men för mig är det viktigare med kvallité och att man är stolt över det man har gjort än hur mycket man får för sin domän när man säljer den. Så till viss del är jag kanske på fel forum och tjatar... :rolleyes:

För att citera Robert Aschberg; Tack för visat intresse och jag fortsätter gärna diskussionen om det finns intresse.

Jag orkade inte läsa det sista inlägget... 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.

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.

Jag slog upp lite mer information, orkar dock inte översätta.

" Triggers can be a very powerful mechanism if used appropriately. The major advantage is that standard functions can be stored within the database and enforced consistently with each update to the database. This can dramatically reduce the complexity of applications. However, there can be some disadvantages:

* Complexity When functionality is moved from the application to the database, the database design, implementation, and administration tasks become more complex.

* Hidden functionality Moving functionality to the database and storing it as one or more triggers can have the effect of hiding functionality from the user. While this can simplify things for the user, unfortunately it can also have side effects that may be unplanned, and potentially unwanted and erroneous. The user no longer has control over what happens to the database.

* Performance overhead When the DBMS is about to execute a statement that modifies the database, it now has to evaluate the trigger condition to check whether a trigger should be fired by the statement. This has a performance implication on the DBMS. Clearly, as the number of triggers increases, this overhead also increases. At peak times, this overhead may create performance problems. "

Citat ur: Connolly T., Begg C., Database systems, 2002, sid. 922

Vyer som SÅDANA ger inte accesskontroll du pratar om. Därför tycker jag det är lite fel att nämna det på det viset. Visserligen har vissa DBMS-ar implementerat dessa på det viset, såsom exempelvis Sybase. Det finns däremot andra som inte fungerar på det viset.

Dvs, för att du ska ha rätt att titta i en vy, måste du ha rätt att titta i tabeller vyn bygger på. Fördelar med vyer är att man slipper göra komplicerade subselects som man annars skulle vara tvungen att göra.

/Zoran

Ja, du kan skapa en vy av order-tabellen som innehåller alla fält utom visakortsnummer-fältet.

Ja, men det hindrar ju inte användaren att försöka göra en select i "modertabellen" och ändå få veta kortnummren. Det är en del servrar där man kan förbjuda access till modertabellerna och sen tillåta access till vyn där den där säkerhetsmodellen fungerar. Som t.ex. Sybase. Däremot finns det servrar där du måste ha access till modertabellerna för att din vyn ska fungera.

/Zoran

Där ser man...
Jag kan förstå att det uppfattas som skryt och det var ju inte meningen. Zorans konstaterande är mer överrensstämmande med verkligheten.
Och visst blir min uppfattning präglad av mina erfarenheter. Personligen har jag några fåtal gånger gjort det ödestigra misstaget att ändra för mycket. Då handlade det om en update med korrekta villkor, men eftersom SQLServers queryanalyzer (precis som många andra verktyg) bara exekverar "markerad kod" i ett skript och inte all kod hade jag för en cut-n-paste bara barkerat update-satsen utan att markera villkoret. Således uppdaterades alla poster. Ett misstag man bara gör en gång. Det hade inte med triggers att göra, men det är lätt att göra ett misstag.

Däremot har triggers (som jag gjort) som förhindrar att t.ex. mer än en rad ändras/uppdateras hittat åtskilliga fel i en applikation som jag gjort databasen till, men där andra personer gör allt annat.

Nu måste jag tyvärr rusa, men jag ska säga ngt snabbt ang views:
Som jag skrev tidigare är jag mer inne på subselects och/eller temptabeller istf views, men det är en smaksak. Dessutom föredrar jag att lägga mer komplicerade frågor och/eller frågor som skall kräva viss behörighet i stored procedures. Men hela view och SP-diskussionen kan vi kanske ta i en annan tråd.

Det har väl "Alla<TM>" gjort :)?

Ja, som du skriver en smaksak. MySQL-utvecklare delar uppenbarligen din åsikt, och de är långt ifrån inkompetenta.

/Zoran