Tillfälligt släppa en trigger

Jag har en ganska viktig trigger i en tabell i min SQL-databas som måste finnas då saker måste göras varje gång man ändrar i tabellen, och det oavsett från vilken procedur det kommer ifrån.

Dock finns det ett tillfälle då triggern inte ska triggas, det är när nånting ska uppdateras från en särskild procedur. Idag har avaktiverar jag triggern tillfälligt när proceduren körs, en disable i början av proceduren och en enable i slutet av proceduren. Dock misstänker jag att servern överbelastas när den proceduren anropas 7000 gånger.

Frågan är, finns det några bättre alternativ?

Vad för server handlar det om då?

Sätt en miljövariabel som kollas innan triggern körs, enkelt att slå av och på. Antar nu oracle och PL/SQL som bas.

Ska vara en trött burk om inte 7k updates bara slinker igenom.

Vad hjälper det? du måste väl ändå 7k ggr inaktivera&aktivera den, eller hur menar du?

Vad är det för lösning med av och på med triggern 7k ggr samtidigt som DB'n är öppen för samtida trafik, låter som en exklusiv batch
"get exclusive lock on table (preferable while others are a sleep), do the shit quickly, open and leave quietly"

Aircode, men typ


EDIT: Månne den skulle reagera vem som uppdaterar tabellen, en speciell användare så hoppas triggern över för att slippa problemet med att låsa databasen då man slagit av triggern.

så villkoret skulle kika på vilken användare som updaterade tabellen och välja att hoppa eller inte.

De har jag inte testat koda, men det borde ju gå tycker jag. Ligger väl i v_$session
Nu var det ett tag sen jag lekte med oracle så jag kan ju ha tokfel.

Frågan var om det går att undvika att triggern exekveras, inte om det går att sätta en session eller global variabel. (globala variabler stöds inte i MS SQL, Oracle och andra vet jag inte)
Oracle har i konstruktionen av en trigger "WHEN (condition)", MS SQL har "INSTEAD OF", detta är antagligen vad TS frågar efter eftersom detta ger stöd för logik kring vad som ska göras när händelsen sker. Det är alltså inte i exekveringen av triggern logiken ska ligga (för sent) utan logiken är kollad till händelsen.

Ehh, en miljövariabel läses med dbms_system.get_env i PL/SQL. Skrev jag global variabel, dom lägger jag i en tabell i så fall.

Jan antog en update, men jag kan väl ha fel. Mitt förslag med en koll på användaren verkar dock lite mer rolig, då behöver man inte låsa ut andra.

Triggern är ju bara lite text som ligger före eller efter det man egentligen vill göra med tabellen.

EDIT: Lägger helst inte sånt i DBMSen alls, lägg den i applikationen som matar data. Fixa med finurliga lösningar i databasen är bara förvirrande.

Rätt information i databasen är ju bara så trist. Om alla helt plötsligt bor på samma adress för att nån glömde ett "where" går ju snabbt att fixa.

Men jag kanske är gammaldags, 3 tier kanske är passé. Får alla pilla direkt i databasen så blir det ju så mycket lättare, eller?

SQL Server 2008

En global variabel är inte samma sak som data i en tabell, nu stöds inte global variabel i MS SQL, i Oracle vet jag inte. Du säger miljö-variabel, vad är scoopet på den? gäller den hela instansen, alltså är den global?

Nej, triggern är inget som bara ligger som text före eller efter det man egentligen vill göra med tabellen. En trigger är ett eget objekt i databasen som automatiskt anropas av motorn när vissa händelser inträffar. DML-triggers kan deklareras för händelserna INSERT, UPDATE och DELETE.
Man kan inte låta bli att få triggern anropad av motorn. Om händelse sker som svara mot att triggern ska anropas och triggern är aktiv så kommer den att exekvera.
Man kan heller inte anropa en trigger direkt.
Triggern kan utför all typ av datamainpulation, den kan till och med få vyer att bli uppdateringsbara men den kan inte ändra i schemat så vitt jag vet.
http://msdn.microsoft.com/en-us/libr...ql.105%29.aspx

När man ska använda triggers kan debatteras men det är klart att det finns situationer då det är att föredra vilket påvisas av dess rena existens.

Ang. "Rätt information", ja, en trigger kan vara ett sätt att säkra detta med.

Ang. "3 tier".
Ett exempel på när logik kan berättigas i DB'n är i mitt tycke när den är väldigt statisk, eller endast syftar till att upprätthålla integriten och/eller ev. flera olika nyttjare av information finns där man inte kan ha logiken och/eller inte kan/vill duplicera logiken så visst, placera den i DB'n. Man får väl vara lite flexibel, om än efter motivering.

Du kan använda replikering.

Vad blev det?

Lägga in villkor i triggern att kolla en @miljövariabel och redigera proceduren att ändra en @miljövariabel för att kolla om det proceduren som körs Christery ville

eller

redigera endast proceduren och låsa hela tabellen som John-Paul ville?

Eller

Behålla den som det är och av/aktivera triggern varje gång i proceduren (och transaktioner på tabellen utförs samtidigt(på rader ej låsta av proceduren) och slinker igenom utan att triggern triggas) som jag tolkat det?


wut?

Proceduren kan köras på en egen databas utan trigger, som replikeras till den första databasen, vars trigger har NOT FOR REPLICATION.

Ett annat alternativ är ju att istället för att disable/enable 7000 gånger, ha triggern avstängd per default, och enable/disable i alla andra procedurer/funktioner (om det är <7000).

Ska tilläggas att jag är inte 100% seriös med nåt av dessa förslag, men det kan ju va värt att ta upp dem för att sedan avskriva dem.