Załóżmy następujący problem: jesteśmy integratorem rozwiązań (czyli nie jesteśmy autorem bazy i oprogramowania które jej używa - nie mamy kodu źródłowego a musimy pewne funkcjonalności dorobić). Mamy tabele A, B i C. Musimy stworzyć trigger wykonujący pewne operacje (w przypadku dodania wierszy) na A i B w zależności od C. Powiązania pomiędzy tabelami mamy takie jeden do wielu z A do B i jeden do wielu z B do C. Schemat taki, w realnym świecie, często jest używany do modelowania dokumentów, czyli A to wiersz nagłówka dokumentu, B to wiersze dokumentu, C to jakieś dodatkowe dane.

Problem polega na tym, że taki trigger jest zasadniczo niewykonalny, szczególnie w sytuacji gdy wpisy w C odnośnie B mogą, ale nie muszą istnieć. W realnym świecie: do systemu dodawany jest dokument (A), a trigger w zależności od C, musi zmodyfikować wiersze dokumentu (B).

Rozwiązaniem takiego problemu, mogłyby być triggrery transakcji. Rozwiązanie które wpadło mi do głowy pod prysznicem, a po którego po krótkim goglowaniu nigdzie nie znalazłem.

Założeniem całego rozwiązania jest to, że dokument jest dodawany w transakcji. Robi tak chyba każdy rozsądny system, tak więc jest to jak najbardziej rozsądne założenie. Trigger transakcji, byłby to rodzaj triggera wykonujący się po zakończeniu transakcji, Oczywiście, aby sprawa miała sens, musimy dodać jeszcze parę sprawa:

  • Transakcja musi być identyfikowalna, np. poprzez nazwę, przykładowa składnia: BEGIN TRANSACTION DodanieDokumentu
  • Dla ułatwienia życia, powinna być wcześnie zadeklarowana w systemie (zwykła rejestracja używanej nazwy transakcji).
  • Trigger transakcji musi być jej częścią, z możliwością wywołania rollbacka lub commita.
To chyba wszystko co niezbędne, cała reszta to już lukier. Czyli:
  1. powinna istnieć dodawania triggera na BEFORE i AFTER transakcji
  2. przy triggerze AFTER, powinna być możliwość dodawania triggrea ON COMMIT, ON ROLLBACK, z możliwośćią zmiany stanu końcowego transakcji (czyli, transakcja chce się rollbackować, ale my ja commitujemy)
  3. powinna istnieć możliwość przekazywania informacji z transakcji do triggera, np. trigger powinien widzieć stworzone w transakcji zmienne i/lub tabele tymczasowe

W praktyce, mogłoby to wyglądać następująco: oryginalny developer definiuje transakcje, i dokumentuje (dla integratorów) że transakcja tworzy tabele tymczasową w której przekazuje wszystkie niezbędne IDki. Integrator w swoim triggerze może wykorzystać tę tabelę i dokonać zmian w momencie gdy wszystkie niezbędne operacje dotyczące dokumentu są już wykonane.

Jeśli ktoś widział tego typu rozwiązanie gdziekolwiek, będzie supr jak się tym podzieli :)

P.S. Oczywiście sens to ma największy kiedy mamy zagnieżdżone transakcje, ale bez zagnieżdżonych też.