Zwischenzeitliche Änderungen an Datenbank erkennen

[hhcm]

Hallo zusammen,

kennt jemand eine Praktikable Lösung um in einer MySQL/MariaDB Umgebung Änderungen an Daten zu erkennen?
Kurz erklärt. Ich öffne eine Datenbankabfrage und gehe in die Pause. Nachdem ich zurück bin, editiere ich einen Datensatz. Wie kann ich erkennen ob an dem Datensatz in meiner Abwesenheit gearbeitet wurde?

Ich glaube bei MySQL gibt es keine "Client"-Events wie z.B bei Oracle. Ich dachte schon an einen Hash den ich dann vor dem Posten nochmal gegen die Datenbank prüfe. Vielleicht gibt es auch bei Unidac etwas (ohne das ich das ganze Handbuch durchsuchen muss)

Hat jemand eine Idee?

[Darlo]

Hi, ich setze immer einen Timestamp bei jeder Änderung.

[hhcm]

Ja, da war ich auch schon.
Es geht auch noch um andere Sachen wie (Existiert der Datensatz überhaupt noch, wurde er bereits abgeschlossen)
Das ganze ist auch noch mit anderen Tabellen verknüppelt (Master/Details) bei den Detail-Datasets würde ich gerade das gleiche wissen.

[jobo]

Im Extremfall kannst Du die (dem System bekannten) alten Werte in die Where Clause für Update/Insert/Delete aufnehmen. Damit erschlägst du eigentlich alles (außer BLOBs)
Nicht schön, aber so machen es auch Profis.
So kannst Du zumindest vermeiden, überall Hash oder Timestamp oder Zählerspalten zu ergänzen.

[Uwe Raabe]

Ich weiß, es geht hier um MariaDB. Trotzdem möchte ich hier kurz auf die bei InterBase verfügbaren Change Views hinweisen, die genau auf diese Problematik zielen. Sollte jemand in Zukunft vielleicht die Wahl der Datenbank haben, kann man sich das Leben damit sehr vereinfachen. Insbesondere auch, da dieses Feature von FireDAC direkt unterstützt wird.

[Frickler]

Zitat:

Zitat von Uwe Raabe (Beitrag 1409522)

Ich weiß, es geht hier um MariaDB. Trotzdem möchte ich hier kurz auf die bei InterBase verfügbaren Change Views hinweisen, die genau auf diese Problematik zielen. Sollte jemand in Zukunft vielleicht die Wahl der Datenbank haben, kann man sich das Leben damit sehr vereinfachen. Insbesondere auch, da dieses Feature von FireDAC direkt unterstützt wird.

Klingt interessant. Vielleicht kommt das ja auch mal irgendwann bei Firebird.

[IBExpert]

Das eine ist das was man deklarativ in einer Datenbank machen kann, in dem man ein paar Befehle
ausführt und wenn man Pech hat, die Größe der Datenbank explodieren lässt und das andere ist
das, was man mit den Mitteln der Datenbank schon lange kann.

Wir nutzen unsere Replikation in Firebird schon seit Jahren auch dafür, das wir eine unlimited
Redo/Undo Log haben und die Entstehungsgeschichte jedes Datensatz der letzten 5 Jahre bei einem
unserer wichtigsten Kunden bei Bedarf nachschauen zu können, und dann nicht nur wer wann was
gemacht hat, sondern auch welche Daten vorher in der Datenbank waren. Die üblichen Felder
create/update user/timestamp in jeder Tabelle kann man sich daher sparen, weil die eh nichtssagend
sind und beim delete eh verloren wären.

Neben der Tatsache, das wir auf dem Wege auch alle gelöschten Datensätze nachvollziehen können,
ist es auch möglich, damit ein Undo zu machen, wenn man weiss, das zu irgendeinem Zeitpunkt
eine Connection gegeben hat, ggf auch nur eine Transaction, deren Operationen rückgängig
gemacht werden sollen. Das Rückgängig machen ist dann der Aufruf einer Stored Proced
mit Parameter für Connection und Optional Transaction ID.

Alle Logs werden jahreweise in eigene Datenbanken gepackt und danach sind die Read Only und müssen
nicht mehr gesichert werden, weil sich nie wieder was ändern kann. Ganz nebenbei hat man
auf dem Wege ein sehr überzeugendes Audit System und falls durch Prüfungen irgendwelche Zweifel
an der Datenqualität aufkommen, findet man mit IP Adresse und Zeitpunkt und ggf Firebird
User sofort den schuldigen und wenn hilfreich, auch den Prozess, der dafür zuständig war.

Die Log DBs sind zusammen mittlerweile ca 700 GB, aber da ist auch der Speed ziemlich egal, weil
man nur selten da dran muss, aber den Vorteil hat, das die nicht auf dem selben Server
gelagert werden müssen, geschweige denn wie bei Changeviews sogar in der selben Datenbank.

Das ist alles wesentlich weniger kompliziert als man denkt und wir haben das auch schon für
mehrere Kunden in deren Firebird Datenbank eingebaut. Bei Interbase geht das nicht, weil
alleine so wichtige Operation wie "execute statement ... on external" nicht existieren
und vieles mehr da eben fehlt.

Wenn Ihr also mit Enterprise Datenmengen zu tun habt, dann vorsichtig sein. Jeder, der mal
eine 500GB Datenbank (egal ob interbase oder Firebird) auf einer lahmen VM auf für Datenbanken
ungeeignete Hardware durch einen Backup Restore schicken musste, weiss, das Nächte dafür
manchmal deutlich zu kurz sind. Da dann auf irgendwelche Brückentags/Feiertagskombinationen
warten zu müssen ist auch keine echte Strategie. Das 500GB auf einem für FB geeigneten Server
auch locker innerhalb von 1-2 Stunden duch einen Backup/Restore laufen können, ist mal nur ganz
am Rande erwähnt.