Ankündigung

Einklappen
Keine Ankündigung bisher.

Loggen von Useraktionen, Mandantenfähigkeit - getrennte Datenbanken

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • 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


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

    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


    --

    Kommentar


    • #3
      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.

      Kommentar

      Lädt...
      X