Für eine PostGreSQL-Datenbank habe ich mal eine Historienverwaltung alleine über Trigger gelöst (die Historientabellen waren getrennte Tabellen und jede Tabelle verfügte über eine Datumsstempel-Spalte 'modified_date').
Es mußte dann in der Anwendungssoftware nichts dafür extra programmiert werden.
Nur der Zugriff auf die archivierten Daten (d.h. anhand eines bestimmten Datums) war eine etwas kompliziertere Stored-Procedure.
Da ich mir bei MySQL nicht sicher bin, ob diese schon Trigger unterstützen, würde ich dir dann zu MS-SQL raten (oder aber eben PostGreSQL).
Für eine PostGreSQL-Datenbank habe ich mal eine Historienverwaltung alleine über Trigger gelöst (die Historientabellen waren getrennte Tabellen und jede Tabelle verfügte über eine Datumsstempel-Spalte 'modified_date').
Wieso nimmst du dafür nicht RULES? Ist doch noch einfacher.
Das schöne an INSERT-only Lösungen ist doch dass sie INSERT-only sind
D.h. man muss weder DELETE noch UPDATE Rechte vergeben.
D.h. man kann *sicher* sein, dass *nie* alte Daten vernichtet werden, egal was die Anwendung macht.
(Natürlich nur solange man davon ausgeht dass das DBMS keinen Bug hat, aber da mache ich mir weniger Sorgen)
Ich finde das immer äusserst beruhigend.
Und natürlich ist es toll für die Beweisbarkeit.
Und es ist eine IMO sehr einfache sowie elegante Lösung.
ich bevorzuge die Methode der 2 Tabellen. Die Tabelle mit den original-Datensaetzen und die Historie mit allen Vergangenen, identifiziert durch eine
steigende Versionsnummer. Je nach Struktur sind Trigger durchaus hilfreich.
Kommt halt drauf an, was bei einer Aenderung noch alles gemacht werden soll. Das
reine wegsichern der Datensaetze in eine Historientabelle mit Version und Datum
ist hier aber mit nem Trigger vorzuziehen. Dann vergisst man es wenigstens nicht
Durchaus kann man in die Historientabelle auch noch den aktuellen Datensatz mit auflisten. Gerade wenn man Versionsdatensaetze fuer einen Benutzer zur Uebersicht
anzeigen moechte, spart man sich hier das zusammenfrimeln aus zwei Tabellen.
Geschmackssache.
_________________ Der Vorteil in der Klugheit besteht darin, dass man sich dumm stellen kann.
(Code::Blocks 10.5, mingw32 gcc 4.4.1)
Ich hab sowas auch mit nem Trigger (Postgresql) gelöst.
Hat den Vorteil, daß egal, wie auf die DB zugegriffen wird. Tool,
Konsoleninterface, Anwendung - auf jeden Fall die Historie geschrieben wird.
Nächstes Thema anzeigen Vorheriges Thema anzeigen
Sie können Beiträge in dieses Forum schreiben. Sie können auf Beiträge in diesem Forum antworten. Sie können Ihre Beiträge in diesem Forum nicht bearbeiten. Sie können Ihre Beiträge in diesem Forum nicht löschen. Sie können an Umfragen in diesem Forum nicht mitmachen.
c++.de ist Teilnehmer des Partnerprogramms von Amazon Europe S.à.r.l. und Partner des Werbeprogramms, das zur Bereitstellung eines Mediums
für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu amazon.de
Werbekostenerstattung verdient werden kann.
Die Vervielfältigung der auf den Seiten www.c-plusplus.de, www.c-plusplus.info, www.c-sar.de, www.c-plusplus.net und www.baeckmann.de
enthaltenen Informationen ohne eine schriftliche Genehmigung des Seitenbetreibers ist untersagt
(vgl. §4 Urheberrechtsgesetz). Die Nutzung und Änderung der vorgestellten Strukturen und Verfahren in
privaten und kommerziellen Softwareanwendungen ist ausdrücklich erlaubt, soweit keine Rechte Dritter verletzt werden.
Der Seitenbetreiber übernimmt keine Gewähr für die Funktion einzelner Beiträge oder Programmfragmente, insbesondere
übernimmt er keine Haftung für eventuelle aus dem Gebrauch entstehenden Folgeschäden.
Twitter
Facebook
