Hello,
Eigentlich sollte diese Logik ohne Trigger gelöst werden, aus deiner Anwendung heraus. Dann hat Du die Probleme nicht. Eine Transaction mit entsprechendem Isolation Level (sprich: Lock-Intensität) brauchst Du dabei auf jeden Fall, weil Du ja mehrere Updates machst, die entweder alle gelingen müssen oder von denen keiner ausgeführt werden darf.
Da möchte ich vehement widersprechen!
Wenn man die Geschäftsregeln in der Datenbank vereinbaren kann, sollte man es auch tun. Alles, was erst in der API vereinbart wird, ist unsicher. Man kann dann niemals mit anderen APIs auf die DB zugreifen (und sicher sein, dass die die Regeln auch einhalten).
Außerdem kann man bei geschickter Trennung von Bewegungsdaten und Bestandsdaten durchaus auf Locks verzichten. Es gilt immer der Grundsatz: nur eine Konsolidierung zur selben Zeit. Und wenn man alle Bewegungsdatensätze, die zu einem Vorgang gehören, auch mit einer eineindeutoigen Vorgangskennung versieht, kann man die Konsolidierung sogar später noch jederzeit wiederherstellen.
Denn Konsolidierung ist das, was der OP hier betreiben will.
Immer hübsch die Trennung einhalten und die Tabellen nicht verknoten.
- Stammdaten
- Bestandsdaten
- Bewegungsdaten
- Reports
Liebe Grüße
Tom S.
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.