Trigger auf Datenbankebene?

[jobo]

Zitat von p80286:

Zitat von jobo:

(und diesen Zustand auch erfolgreich sicherstellen kann)

Um die Bedeutung zu unterstreichen hättest Du einen etwas größeren Font wählen sollen.

Gruß
K-H

Ja, könnte... aber diese Diskussion ist irgendwie .. ich weiß auch nicht.
Es gibt halt Freunde der Persistenzsysteme, die DB Blackbox Fans usw. die einfach die DB tauschen können. Und es gibt die sagen wir "traditionelle" Seite. Da würde ich mich auf jeden Fall einsortieren. Sicher gibt es auch Kompromisse. Ein App Server an einer DB ist für sich genommen auch ein C/S System, dass man nach den klassischen Regeln fahren kann.
Es spricht ja nichts dagegen, andere Wege zu gehen oder andere Prioritäten zu setzen. Man muss sich halt bewusst sein, was das bedeutet.

Offenbar ist es ja wohl so, dass viele Delphi im DB Bereich so einsetzen, dass die komplette Business Logik in der Anwendung liegt. Bei spezialisierten, homogenen Systemen ist das wohl okay. Und es hat ja durchaus ein paar positive bzw. willkommene Nebeneffekte. Die Business Logik und die Constraints kann mir keiner "klauen" oder einfach per Datenmodell kopieren.

Ich habe schon high end Systeme gesehen, wo mir schlecht wurde, kein einziger Konstraint, auch nicht für foreign keys, fürchtliche Namensgebung, also inkonsistent usw usf.
Und da kann man doch nur zu dem Schluss kommen, dass es primär um Obfuscation geht.

Solange ich Robustheit, Transaktionssicherheit, Konsistenz gewährleisten kann ist ja alles gut.
Ich habe allerdings oft den Eindruck, dass die Probleme vielen gar nicht so klar sind. Ebensowenig die Möglichkeiten die ein stinknormales DB System von Haus aus bietet.
Und zur Großschreibung: wahrscheinlich mach ich mich mit Beiträgen wie diesen eh schon zum Affen.

[p80286]

Zitat von jobo:

Offenbar ist es ja wohl so, dass viele Delphi im DB Bereich so einsetzen, dass die komplette Business Logik in der Anwendung liegt. Bei spezialisierten, homogenen Systemen ist das wohl okay. Und es hat ja durchaus ein paar positive bzw. willkommene Nebeneffekte. Die Business Logik und die Constraints kann mir keiner "klauen" oder einfach per Datenmodell kopieren.

Ja so etwas gibt/gab es, und aus bitterer Erfahrung, das ist nicht optimal.
Sobald irgendetwas (und sei es das Antwortverhalten) die Kommunikation zwischen Client und Server stört, bekommst die Datenhack.

Zitat von jobo:

Ich habe schon high end Systeme gesehen, wo mir schlecht wurde, kein einziger Konstraint, auch nicht für foreign keys, fürchtliche Namensgebung, also inkonsistent usw usf.
Und da kann man doch nur zu dem Schluss kommen, dass es primär um Obfuscation geht.

Nö eher 2...9 Programmierer die jeweils ein Stückchen angeflickt haben, und wo jeder ein individuelles Verhältnis zur Aufgabenstellung hat(te)
[Welcher Chef will schon eine DB verbessern, wenn es bisher auch so ohne große Probleme ging?]

Zitat von jobo:

Solange ich Robustheit, Transaktionssicherheit, Konsistenz gewährleisten kann ist ja alles gut.
Ich habe allerdings oft den Eindruck, dass die Probleme vielen gar nicht so klar sind. Ebensowenig die Möglichkeiten die ein stinknormales DB System von Haus aus bietet.
Und zur Großschreibung: wahrscheinlich mach ich mich mit Beiträgen wie diesen eh schon zum Affen.

Solange jemand weiß was er tut.... das geht so lange gut, bis jemand abschreibt und nicht genau weiß was er tut...

Darum ein solidarisches OinkOink
K-H

P.S.
@all Nein, das ist kein Rundumschlag, und ich weiß, daß hier genug Leute mitlesen, die das nicht für die Erbsenzählerei von ein paar Spinnern abtun.

[nahpets]

Zitat von jobo:

Und zur Großschreibung: wahrscheinlich mach ich mich mit Beiträgen wie diesen eh schon zum Affen.

Nein, absolut nicht. Im Gegenteil, es ist erfrischend, wenn man mal fundiertes KnowHow zu lesen bekommt.

Mein Eindruck aus ca. 30 Jahren Programmiererfahrung ist eher, dass ein nicht unerheblicher Teil der Programmierer (die ich habe kennen lernen dürfen, also nicht allgemeinglobalgalaktisch) und die Software schrieben, deren Datenhaltung eine Datenbank voraussetzte, über erschreckend geringe Datenbankkenntnisse verfügten.
Daraus resultiert dann eben auch, dass man alles im Programm macht (egal welche Mengengerüste da zu verarbeiten sind) und die Datenbanklogik gegen 0 tendiert. Hauptsache die Daten sind irgendwie in der Datenbank und können mit "dem eigenen Programm" sinnvoll verarbeitet werden.

Aber das jetzt weiter auszuführen wäre arg OffTopic.

[jobo]

Hach, soviel Zuspruch ist schon irgendwie tröstlich.

Aber es geht ja nicht um meine Bedenkenträgerschaft. Und bis jetzt kam noch kein Hinweis, dass all die Einwände berechtigt sind. Also ist es eine Standalone Anwendung oder nicht,,
Die Frage wäre, ob der TE noch mitverfolgt, was hier geschrieben wird, bzw. ob man noch konkrete Hilfestellung leisten kann oder er schon "geflüchtet" ist.

Dazu ein Vorschlag was die "Parameter" Frage angeht.
Wenn es eine Mapping Tabelle gibt, die gepflegt ist, kann ich eine Funktion schreiben, die mir den gemappten User anhand des eingeloggten Users liefert. Die rufe ich im Triggerbody auf und hab was ich brauche, ohne Parameter.
Dann ist es nur etwas Fleißarbeit, alle Trigger zu schreiben (oder zu generieren). Einzige(?) Voraussetzung wäre dann nur, dass nicht bereits Trigger vorhanden sind. Die müssten man dann bei Mariadb offenbar mergen?

[nahpets]

Ausgehend von https://mariadb.com/kb/en/sql-99/act...n-of-triggers/ kann man bei MariaDB mehrere Trigger für eine Tabelle erstellen, die nacheinander abgearbeitet werden.

Gegeben sei:

SQL-Code:

CREATE TRIGGER Trigger_1 AFTER UPDATE ON Table_1 ...;

CREATE TRIGGER Trigger_2 BEFORE UPDATE ON Table_1 ...;

CREATE TRIGGER Trigger_3 AFTER UPDATE ON Table_1 ...;

Zuerst wird Trigger_2 ausgeführt, dann Trigger_1 und anschließend Trigger_3.

Wenn ich das halbwegs richtig sehe, müsste man hier also automatisch für alle Tabellen einen zusätzlichen Trigger generieren können, der, da zuletzt erstellt, auch zuletzt ausgeführt wird. Im Trigger kann man dann eine Funktion aufrufen, die den Usernamen, auf einem der hier bereits beschriebenen Wege, ermittelt und in die Datenbank schreibt.

Ungefähr sowas sollte sinngemäß gehen:

SQL-Code:

CREATE TRIGGER Tabellenname_Insert
BEFORE INSERT ON Tabellenname
  REFERENCING NEW ROW AS New
FOR EACH ROW
BEGIN ATOMIC
  SET New.UserName = FuntionZurBenutzernemenermittlung;
  SET New.Datum = Current_Date;
END

Was ich nicht habe finden können ist, ob ein Trigger auch für mehrere Ereignisse aufgerufen werden kann, also ein

BEFORE INSERT OR UPDATE ON Tabellenname

Es scheint aber eher nicht der Fall zu sein, so dass halt je Tabelle zwei Trigger benötigt werden:

SQL-Code:

CREATE TRIGGER Tabellenname_Insert BEFORE INSERT ON Tabellenname

CREATE TRIGGER Tabellenname_UPDATE BEFORE UPDATE ON Tabellenname

Inhaltlich können sie identisch sein.

Die oben verlinkte Dokumentation zu MariaDB ist sehr ausführlich und sollte für alle MariaDB-Nutzer zur Pflichtlektüre gehören und als ersten Anlaufstelle bei Fragen dienen.

Der Triggerquelltext läßt sich vermutlich sogar per SQL über INFORMATION_SCHEMA.TABLES generieren, sowas in der Art:

SQL-Code:

select 
  ConCat('CREATE TRIGGER TRI_',Table_Name,
  ' BEFORE INSERT ON ',Table_Name,
  ' REFERENCING NEW ROW AS New FOR EACH ROW',
  ' BEGIN ATOMIC',
  ' SET New.UserName = FuntionZurBenutzernemenermittlung;'
  ' SET New.Datum = Current_Date;',
  ' END') as SQL_Statement
from INFORMATION_SCHEMA.TABLES 
where TABLE_SCHEMA = 'DasBenutzerSchema' 
and   Table_Name like 'ErforderlicheEinschränkungFürBenötigteTeilmenge%';

Das Ergebnis müsste man dann irgendwie per Batch oder so abarbeiten.

Eventuell ginge es auch innerhalb einer Prozedur über Execute Immediate (https://mariadb.com/kb/en/mariadb/execute-immediate/), aber da hab' ich jetzt keine Lust, das herauszufinden.

[mkinzler]

Dann wäre die folgende Aussage falsch:

https://mariadb.com/kb/en/mariadb/trigger-limitations

[jobo]

Interessant, dann würde ich wohl eher den offiziellen Limitations folgen, als dem Nachdruck eines SQL 99 Buches von dem auf der Seite geschrieben steht:

Zitat:

This page is part of the book SQL-99 Complete, Really, by Peter Gulutzan & Trudy Pelzer. The authors have graciously allowed us to reproduce the contents of the book here. Because the book is about the SQL-99 standard, the contents of this and other pages in the book may not directly apply to MariaDB. Use the navigation bar to navigate the book.

[nahpets]

Die beiden Seiten Trigger Limitations und Activation of Triggers scheinen sich in ihren Aussagen zu widersprechen.

Ok, wenn man weiterliest: Der zweite Link bezieht sich auf den SQL-99-Standard. Das dort beschriebene muss nicht zwingend mit MariaDB funktionieren.

Hiernach scheint es aber ab MariaDB 10.2.3 zu funktionieren: Information Schema TRIGGERS Table

Zitat von ACTION_ORDER:

Indicates the order that the action will be performed in (of the list of a table's triggers with identical EVENT_MANIPULATION and ACTION_TIMING values). Before MariaDB 10.2.3 introduced the FOLLOWS and PRECEDES clauses, always 0