[ric]

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

[zoran]

Originally posted by grazzy@Dec 4 2004, 12:01
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.

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

[grazzy]

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

[zoran]

Originally posted by grazzy@Dec 4 2004, 20:56
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

[eg0master]

Ursprungligen postat av zoran

Nja, jag tror egomaster vet nog vad han pratar om. Hans argument är inte tagna ur luften och verkar vara hans egna.

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.

[zoran]

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.

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

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.

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

/Zoran