Triggerlösung, da nur von der Datenbank abhängig, egal wie die Daten in die Datenbank kommen, das funktioniert dann immer.
Ansonsten muss jeder Weg, der Daten in die Datenbank bringt, die passende Geschäftslogik selbst mitbringen.
D.h.: Ggfls. redundante Implementierung identischer Logik. Das ist fehleranfällig und hat meist einen sehr hohen Pflegebedarf.
Jede Änderung der Logik muss dann an x Stellen mitgepflegt werden.
Ist je Datenbank oder je Niederlassung eine etwas andere Geschäftslogik erforderlich, wird die auch nur einmal je Datenbank in deren Triggern gepflegt.
In welchen Mengen werden die Daten eingeflegt? Muss die Select-Abfrage in "Massen" ausgeführt werden oder ab und an mal, wenn gerade jemand was an den Daten ändert. Dann sind ein paar Millisekunden für eine zusätzliche Abfrage eher vernachlässigbar.
Werden die Rechnungen einzeln, bei Bedarf erstellt oder eher zu "ein paar Millionen" im Batch?
Ist nur ein Schalter zu prüfen, dann hat die passende Tabelle halt eben nur einen Datensatz mit einer Spalte und dem entsprechenden Wert. Das ist dann so schnell, wie das oracletypische
select sysdate from dual;
.
Je nach Datenbank kann man sich das dann noch in eine Funktion packen und im Trigger in der Form
SQL-Code:
if UseLager then begin
-- mach was mit den Daten
end
nutzen.
Bei Oracle kann man in Packages im Initialisierungsteil (
http://oracle-apex.blog/?p=45) Werte in Variabeln einlesen. Die behalten dann Gültigkeit, bis man die Datenbank runterfährt oder das
Package neu lädt. Wenn man nun in 'nem Trigger auf diese Variabeln des Packages zugreift, so hat man da keine Select-Laufzeit-Probleme. Das ist genauso schnell, wie der Zugriff auf irgendeine beliebige Variabel in 'nem beliebigen Programm. Keine Ahnung, ob man das auf andere Datenbanken übertragen kann, aber als Denkansatz für die Lösungssuche eventuell brauchbar.