[eg0master]

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...

[David]

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.

[Thomas]

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

[zoran]

Originally posted by eg0master@Dec 2 2004, 23:49
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...

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

[eg0master]

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.

[David]

Originally posted by eg0master@Dec 3 2004, 12:52
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.

[eg0master]

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.

[Clarence]

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.

[eg0master]

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.

men för utvecklaren som vet vad han gör är det självklart en väldigt bra sak

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...

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

[David]

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.