Tweet
Hallo,
ich entwerfe gerade für ein größtenteils bereits bestehendes Projekt (Prozessdaten-/Produktionsdaten-Dokumentation) ein Logging von Änderungen. Ein paar hundert Benutzer greifen derzeit über ein PHP-FrontEnd auf die DB zu, wobei die Zugriffssteuerung/Rechtemanagement komplett in PHP liegt, d.h. alles über einen DB-User läuft. 85% der Businesslogik liegen im FrontEnd, der Rest in Oracle. Löscht ein Benutzer irgendwelche Prozessdaten, soll dies als eine Bemerkung in den späteren Berichten auftauchen. Die gelöschten Daten müssen somit noch im Sytsme hinterlegt bleiben, aber eine rein textuelle Form reicht hier ("Benutzer xyz hat den Wert 47 auf 11 geändert.").
Vorab zur Info: Die Tabellen, für welche das Logging benötigt wird, haben alle zwischen 20.000 bis 300.000 Einträge pro Jahr, wobei hier mind. die letzten 5 Jahre vorgehalten Werden. Von Interesse sind ca. 10 Tabellen.
Ich habe vier Lösungsansätze und möchte Euch bei der Entscheidung einbeziehen:
1) Man lässt die Werte in den entsprechenden Tabellen stehen. Das FrontEnd setzt lediglich per Update drei Spalten (gelöscht, von wem, am/um). Die BEmerkung wird bei Bedarf dynamisch aus den Werten generiert.
Nachteil: Die Tabellen haben oft PKs bestehend aus 2 oder 3 Spalten (bsp. Auftragsnummer + Materialnummer), welche - da laut Projektdefinition unveränderlich und eindeutig - alle Kriterien eines Primärschlüssels erfüllen. Setzt man hier einen Eintrag nur auf gelöscht, so kann eine gleiche Kombination später nicht wieder hinzugefügt werden, da der PK verletzt werden würde. Also müssten alle Tabellen überarbeitet und mit Sequentiellen PKs ausgestattet werden. Des Weiteren ist das 'ständige' generieren der Texte eine unnötige Performance-Last - auch wenn man hier nicht unbedingt von Last sprechen kann.
2) Man löscht die Einträge per normalen Delete und erzeugt über einen Trigger eine entsprechende Bemerkung in einer Tabelle, welche alle Bemerkungen des Systems beinhaltet. Der Text wird nur einmal generiert und liegt somit perforemance-sparend vor.
Nachteil: Bei einer normalen Delete-DML kann das FrontEnd keinen Benutzernamen übergeben, was aber eine recht wichtige Information darstellt (oder geht das doch irgendwie?).
2.1) Man erstellt für jede Tabelle eine Prozedure welche vom FrontEnd aufgerufen wird. Diese nimmt die Löschung und die Erzeugung der Bemerkung vor. Ihr könnte neben den PKs auch der Bennutzername übergeben werden.
Nachteil: Für jede Tabelle eine Prozedure?!?
2.2) Man erstellt für jede Tabelle eine View, welche eine extra Spalte für den Lösch-Benutzernamen hat. Wird hier einer eingetragen, löscht ein instead-of Trigger die Zeile in der Tabelle und erzeugt die Bemerkung in der globalen Bemerkungstabelle.
Nachteil: Für jede Tabelle eine View?!?
2.3) Die Business-Logik im FrontEnd macht nach dem Delete der Daten ein Update der Bemerkung, bzw. des Benutzernamens.
Nachteil: Zwei DMLs von Extern pro Löschvorgang.
3) Das FrontEnd dokumentiert nach dem Delete den Vorgang als Bemerkung in der DB. Somit wird die Zuständigkeit von der DB auf das FrontEnd verlagert.
Nachteil: Wieder zwei DMLs von Extern pro Löschvorgang.
Am schönsten wäre natürlich eine Lösung, welche für das FrontEnd transparent läuft.
Was würdet Ihr bevorzugen? Ich tendiere ein wenig zu 2.2, bin aber noch etwas unschlüssig.
ich entwerfe gerade für ein größtenteils bereits bestehendes Projekt (Prozessdaten-/Produktionsdaten-Dokumentation) ein Logging von Änderungen. Ein paar hundert Benutzer greifen derzeit über ein PHP-FrontEnd auf die DB zu, wobei die Zugriffssteuerung/Rechtemanagement komplett in PHP liegt, d.h. alles über einen DB-User läuft. 85% der Businesslogik liegen im FrontEnd, der Rest in Oracle. Löscht ein Benutzer irgendwelche Prozessdaten, soll dies als eine Bemerkung in den späteren Berichten auftauchen. Die gelöschten Daten müssen somit noch im Sytsme hinterlegt bleiben, aber eine rein textuelle Form reicht hier ("Benutzer xyz hat den Wert 47 auf 11 geändert.").
Vorab zur Info: Die Tabellen, für welche das Logging benötigt wird, haben alle zwischen 20.000 bis 300.000 Einträge pro Jahr, wobei hier mind. die letzten 5 Jahre vorgehalten Werden. Von Interesse sind ca. 10 Tabellen.
Ich habe vier Lösungsansätze und möchte Euch bei der Entscheidung einbeziehen:
1) Man lässt die Werte in den entsprechenden Tabellen stehen. Das FrontEnd setzt lediglich per Update drei Spalten (gelöscht, von wem, am/um). Die BEmerkung wird bei Bedarf dynamisch aus den Werten generiert.
Nachteil: Die Tabellen haben oft PKs bestehend aus 2 oder 3 Spalten (bsp. Auftragsnummer + Materialnummer), welche - da laut Projektdefinition unveränderlich und eindeutig - alle Kriterien eines Primärschlüssels erfüllen. Setzt man hier einen Eintrag nur auf gelöscht, so kann eine gleiche Kombination später nicht wieder hinzugefügt werden, da der PK verletzt werden würde. Also müssten alle Tabellen überarbeitet und mit Sequentiellen PKs ausgestattet werden. Des Weiteren ist das 'ständige' generieren der Texte eine unnötige Performance-Last - auch wenn man hier nicht unbedingt von Last sprechen kann.
2) Man löscht die Einträge per normalen Delete und erzeugt über einen Trigger eine entsprechende Bemerkung in einer Tabelle, welche alle Bemerkungen des Systems beinhaltet. Der Text wird nur einmal generiert und liegt somit perforemance-sparend vor.
Nachteil: Bei einer normalen Delete-DML kann das FrontEnd keinen Benutzernamen übergeben, was aber eine recht wichtige Information darstellt (oder geht das doch irgendwie?).
2.1) Man erstellt für jede Tabelle eine Prozedure welche vom FrontEnd aufgerufen wird. Diese nimmt die Löschung und die Erzeugung der Bemerkung vor. Ihr könnte neben den PKs auch der Bennutzername übergeben werden.
Nachteil: Für jede Tabelle eine Prozedure?!?
2.2) Man erstellt für jede Tabelle eine View, welche eine extra Spalte für den Lösch-Benutzernamen hat. Wird hier einer eingetragen, löscht ein instead-of Trigger die Zeile in der Tabelle und erzeugt die Bemerkung in der globalen Bemerkungstabelle.
Nachteil: Für jede Tabelle eine View?!?
2.3) Die Business-Logik im FrontEnd macht nach dem Delete der Daten ein Update der Bemerkung, bzw. des Benutzernamens.
Nachteil: Zwei DMLs von Extern pro Löschvorgang.
3) Das FrontEnd dokumentiert nach dem Delete den Vorgang als Bemerkung in der DB. Somit wird die Zuständigkeit von der DB auf das FrontEnd verlagert.
Nachteil: Wieder zwei DMLs von Extern pro Löschvorgang.
Am schönsten wäre natürlich eine Lösung, welche für das FrontEnd transparent läuft.
Was würdet Ihr bevorzugen? Ich tendiere ein wenig zu 2.2, bin aber noch etwas unschlüssig.
Comment