Loggen von Useraktionen, Mandantenfähigkeit - getrennte Datenbanken

aeris · 27.08.2010, 09:28

Hallo,

ich stehe vor der Aufgabe in ein bestehendes Projekt eine Logger Funktion praktisch aller Useraktionen einzubetten.

Ja, prinzipiell ist das keine große Aufgabe

Es handelt sich in diesem speziellen Fall um eine Mandantenfähige SAAS-Lösung. Die Trennung der Mandantendaten erfolgt über verschiedene Datenbanken, d.h eine Applikation - X Datenbanken. Applikation entscheidet nach Anmeldung auf welche DB zugegriffen werden muss.

Die Applikaton selbst besteht aus einer großen Anzahl von Modulen, die sich wiederrum in mehrere kleine Module aufteilen.
Die Anwendung wird auch noch stetig weiterentwickelt, es werden also immer wieder neue Module hinzukommen.

Mir stellt also nun die Frage, wie dieses Loggen am sinnvollsten implementiert werden kann um alle Aktionen in bestehenden Modulen zu loggen, sowie auch künftige Module ohne großen Aufwand in den Logger miteinzubeziehen.

Die Speicherung der Aktionen sollte DB-basiert erfolgen, da die Historie der Useraktionen 1. dem Administrator gesammelt präsentiert werden soll und 2. in bestimmten Modulen auch für alle User nachvollziehbar sein muss (Filtermöglichkeiten, "User X hat am xx.xx.xxx Kommentar y bearbeitet").

Mein Ansatz ist bisher folgender:
Modul, Sub-Modul, User-ID, ID des bearbeiteten/gelöschten/hinzugefügten Datensatzes/Files/..., ID der Aktion (CRUD o.ä) werden in einer Log-Tabelle gespeichert.
Aufgrund der ID's (Modul, Sub-Modul, "FremdID") kann beim späteren Aufruf der Hostrie entschieden werden welche Daten aus der Tabelle geholt werden müssen und wie diese in einer menschenlesbarer Form präsentiert werden können.

Was mich an diesem Ansatz stört ist, dass in der DB keine wirklichen Fremdschlüssel usw. implementiert werden können da ja FK's verschiedener Tabellen geloggt werden. Der Vorteil ist natürlich, dass neue Module in der Loggerklasse nur über eine weitere ID definiert werden müssen.

Ein Datenbanktechnsich weitaus sauberer Ansatz wäre, jedes Modul in einer eigenen Tabelle zu loggen.
Hier stört mich aber, dass beim Hinzufügen von neuen Modulen in jeder Mandantendatenbank ebenfalls eine neue Tabelle angelegt werden müsste - was m.M.n über kurz oder lang die Datenbanken unnötig aufbläht und die Wartung noch schwerer macht als bisher.
Auch das Archivieren der Logdaten würde sich hier schwieriger/aufwendiger gestalten.

Ich bin für jeden Pro/Kontrapunkt der euch zu meinen Ansätzen einfällt dankbar. Und natürlich auf für völlig neue Ansätze die ich bis jetzt womöglich übersehen habe

nikosch · 27.08.2010, 12:52

Ich finde erstgenanntes jetzt nicht so tragisch. Bei der Logauswertung gehts gewöhnlich ja weniger um Performance.

aeris · 27.08.2010, 14:01

Nunja, so ganz unwichtig ist der Punkt Performance in diesem Fall nicht, da in bestimmten Views jeweils eine Historie des entspr. Submoduls immer und für jeden angezeigt werden soll/muss (z.B. die letzten 30 Aktionen).

Eine weitere Idee die ich heute Vormittag hatte wäre die "unwichtigen" Aktion (nur für den Admin sichtbar) getrennt von jenen, die jedem präsentiert werden sollen, zu loggen.
Ob dies in Punkto Performance/einfacheres Handling für die Entwickler wirklich einen Vorteil bringen könnte... Ich bin mir nicht wirklich sicher. Wahrscheinlich eher nicht.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
2 Datenbanken gleichzeitig überschreiben ?	danyh	Datenbanken	3	10.03.2010 16:29
Datenbanken abgleichen (getrennte Server)	FreAkaZoiD	PHP Tipps 2008	6	10.10.2007 20:14
Zwei Datenbanken gegenseitig überprüfen	FleyerShaver	Datenbanken	5	28.06.2007 23:36
Script zum loggen von Bannerklicks	$$$ ThiKool $$$	HTML, Usability und Barrierefreiheit	14	10.11.2006 01:15
Datenbanken von Windows zu Linux	ApfeL	Server, Hosting und Workstations	1	12.04.2006 20:31
SELECT über mehrere Datenbanken?	Transmitter	Datenbanken	10	29.01.2006 13:30
Mysql Datenbanken verknüpfen oder so +g+		PHP Tipps 2005-2	3	29.10.2005 15:36
Eine Datenbank - Viele Tabellen oder mehrere Datenbanken?	nicobischof	Datenbanken	3	20.10.2005 15:36
Zwei Datenbanken auslesen		PHP Tipps 2005-2	5	09.08.2005 17:05
Andere Datenbanken als MySQL		PHP Tipps 2005-2	3	15.07.2005 14:05
mehrere Datenbanken oder lieber nur eine die...	Crypi	Datenbanken	2	09.07.2005 12:03
[Erledigt] MSSQL Datenbanken auslesen		Off-Topic Diskussionen	4	01.06.2005 00:41
[Erledigt] Mehrere Datenbanken auf verschiedenen Servern		Datenbanken	2	15.05.2005 22:28
PHP und MySQL Datenbanken	GELight	Datenbanken	3	25.12.2004 09:56
Mehrere Datenbanken ansprechen		PHP-Fortgeschrittene	8	14.09.2004 20:56

27.08.2010, 09:28
aeris Benutzer Registriert seit: 24.07.2010 Beiträge: 91 PHP-Kenntnisse: Fortgeschritten	Loggen von Useraktionen, Mandantenfähigkeit - getrennte Datenbanken Hallo, ich stehe vor der Aufgabe in ein bestehendes Projekt eine Logger Funktion praktisch aller Useraktionen einzubetten. Ja, prinzipiell ist das keine große Aufgabe Es handelt sich in diesem speziellen Fall um eine Mandantenfähige SAAS-Lösung. Die Trennung der Mandantendaten erfolgt über verschiedene Datenbanken, d.h eine Applikation - X Datenbanken. Applikation entscheidet nach Anmeldung auf welche DB zugegriffen werden muss. Die Applikaton selbst besteht aus einer großen Anzahl von Modulen, die sich wiederrum in mehrere kleine Module aufteilen. Die Anwendung wird auch noch stetig weiterentwickelt, es werden also immer wieder neue Module hinzukommen. Mir stellt also nun die Frage, wie dieses Loggen am sinnvollsten implementiert werden kann um alle Aktionen in bestehenden Modulen zu loggen, sowie auch künftige Module ohne großen Aufwand in den Logger miteinzubeziehen. Die Speicherung der Aktionen sollte DB-basiert erfolgen, da die Historie der Useraktionen 1. dem Administrator gesammelt präsentiert werden soll und 2. in bestimmten Modulen auch für alle User nachvollziehbar sein muss (Filtermöglichkeiten, "User X hat am xx.xx.xxx Kommentar y bearbeitet"). Mein Ansatz ist bisher folgender: Modul, Sub-Modul, User-ID, ID des bearbeiteten/gelöschten/hinzugefügten Datensatzes/Files/..., ID der Aktion (CRUD o.ä) werden in einer Log-Tabelle gespeichert. Aufgrund der ID's (Modul, Sub-Modul, "FremdID") kann beim späteren Aufruf der Hostrie entschieden werden welche Daten aus der Tabelle geholt werden müssen und wie diese in einer menschenlesbarer Form präsentiert werden können. Was mich an diesem Ansatz stört ist, dass in der DB keine wirklichen Fremdschlüssel usw. implementiert werden können da ja FK's verschiedener Tabellen geloggt werden. Der Vorteil ist natürlich, dass neue Module in der Loggerklasse nur über eine weitere ID definiert werden müssen. Ein Datenbanktechnsich weitaus sauberer Ansatz wäre, jedes Modul in einer eigenen Tabelle zu loggen. Hier stört mich aber, dass beim Hinzufügen von neuen Modulen in jeder Mandantendatenbank ebenfalls eine neue Tabelle angelegt werden müsste - was m.M.n über kurz oder lang die Datenbanken unnötig aufbläht und die Wartung noch schwerer macht als bisher. Auch das Archivieren der Logdaten würde sich hier schwieriger/aufwendiger gestalten. Ich bin für jeden Pro/Kontrapunkt der euch zu meinen Ansätzen einfällt dankbar. Und natürlich auf für völlig neue Ansätze die ich bis jetzt womöglich übersehen habe


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

27.08.2010, 12:52
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 34.256 PHP-Kenntnisse: Fortgeschritten	Ich finde erstgenanntes jetzt nicht so tragisch. Bei der Logauswertung gehts gewöhnlich ja weniger um Performance. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

27.08.2010, 14:01
aeris Benutzer Registriert seit: 24.07.2010 Beiträge: 91 PHP-Kenntnisse: Fortgeschritten	Nunja, so ganz unwichtig ist der Punkt Performance in diesem Fall nicht, da in bestimmten Views jeweils eine Historie des entspr. Submoduls immer und für jeden angezeigt werden soll/muss (z.B. die letzten 30 Aktionen). Eine weitere Idee die ich heute Vormittag hatte wäre die "unwichtigen" Aktion (nur für den Admin sichtbar) getrennt von jenen, die jedem präsentiert werden sollen, zu loggen. Ob dies in Punkto Performance/einfacheres Handling für die Entwickler wirklich einen Vorteil bringen könnte... Ich bin mir nicht wirklich sicher. Wahrscheinlich eher nicht.