Trigger auf Datenbankebene?

[p80286]

Zitat von mikhal:

Ich würde es im Programm realisieren: In deiner Zugriffskomponente (vermutlich Query) gibt es das Event BeforePost, hier kannst du den Benutzernamen ermitteln und in die gewünschten Tabellenfelder eintragen.

Dann ist aber jeder DB-Nutzer, der Dein Programm nicht nutzt, außen vor. Darüber muß man sich im klaren sein.

Gruß
K-H

[mikhal]

Ja, das ist wohl so. Aber eine solche Forderung geht aus der Frage des TE nicht hervor. Wahrscheinlich wurde die Anforderung erst später angefragt.

Grundsätzlich ist die Verwendung eines Datenbank-Triggers hier der bessere Weg, wenn man diese Daten grundsätzlich bei jedem Insert- oder Update-Statement verwenden möchte. Aber dann benötigt der TE eine Tabelle mit den Benutzern, gegen die sich die Anwender anmelden müssen, damit er die Namen ziehen kann. War auch mein erster Gedanke, aber ist wohl beim TE nicht vorgesehen oder war nicht geplant. Wenn ich es richtig verstanden habe, werden DB-User angemeldet, die über eine Rolle verfügen. Und ja, er muss die Trigger für jede Tabelle anlegen, ein Aufwand, den er nicht treiben wollte.

Über das Event muss er das dann aber auch machen, kann aber wie oben beschrieben eine Standard-Routine verwenden, um den Aufwand zu reduzieren.

Grüße
Mikhal

[jobo]

Zitat von mikhal:

Ja, das ist wohl so.
..

Grundsätzlich ist die Verwendung eines Datenbank-Triggers hier der bessere Weg,
..

Klar, ein Server ist ein Server.
Wenn es wasserdicht sein soll, müssen solche Operationen auf dem DB Server erfolgen.

Wenn ich ein C/S System so definiere, dass mein (Delphi)Client den einzigen Zugriff hat (und diesen Zustand auch erfolgreich sicherstellen kann), dann kann ich natürlich hier alle möglichen Mätzchen machen, von Logging bis Business Logic.
Sobald mehr als ein System auf die DB durchgreift (vor allem schreibend), bin ich natürlich gekniffen. Theoretisch entgleitet das bereits, wenn ich einen Release Candidate des gleichen Sytems auf eine Produktivdb loslasse. Naja, ich will den Teufel nicht an die Wand malen. Wenn man weiß was man tut, ist vieles möglich.

Ich hatte allerdings die Anforderung des TE so verstanden, dass er nicht alle / so viel Altdaten "nachverarbeiten" will. Aber vlt geht es darum gar nicht.

Zitat von himitsu:

Die Dokumentation von z.B. MSSQL hat das ähnlich.

Ja, kann sein. Ich hab keinen so detailierten Überblick was die DB auf Triggerebene alles können / unterscheidet.
Aber das von Dir erwähnte Verfahren kenne ich so halt von Postgres und eben nicht von Maria.

[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

[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?