Individueller Zeitstempel -> individuelles DB-Feld in User-Tabelle problematisch?
Eingetragen von C_Logemann (896)am 10.12.2008 - 10:54 Uhr in
Hallo Community,
ich benötige einen individuellen Zeitstempel (wenn User eine bestimmte Seite aufrufen), um an anderer Stelle im Template in Abhängigkeit davon Daten auszugeben.
Es fallen mir zwei Lösungen ein:
- Lösung A ist schnell und einfach, aber evtl. problematisch.
- Lösung B ist sauberer und flexibler, aber dafür etwas umfangreicher.
- Vielleicht weiß jemand ja noch eine oder mehrere andere Lösungen, gar bestehende Module?
Im Moment soll diese kleine Lösung zwar in einer Drupal 5-Umgebung eingesetzt werden, aber da ich längerfristig plane, interessieren mich auch Drupal 6 und 7+ :-)
Lösung A:
Da der Zeitstempel bei jedem registriertem User benötigt wird, bietet sich auf dem ersten Blick die User-Tabelle an, in die ich mit Phpmyadmin ein weiteres Feld einfügen könnte. Somit bräuchte ich nur bei Aufruf besagter Aktivierungs-Seite im Template die aktuelle Zeit per UPDATE in das entsprechende Feld des Users zu schreiben. Das Auslesen mit SELECT ist ja kein Problem. Diese Funktionalität müsste ich noch nicht mal unbedingt in einem custom_modul unterbringen, denke ich.
Ich kann mir einerseits vorstellen, daß die erweiterte Nutzung von Tabellen Konflikte hervorrufen, aber auch Performance-Vorteile bieten kann. Daß diese Lösung außerhalb einer Custom-Umgebung eher Konflikte hervorrufen könnte, wenn diese Strategie mehrere Modul-Entwickler einsetzen würden, ist mir klar. Dafür würde ich dann auch Lösung B bevorzugen (oder eine andere, saubere Trennung).
Die wichtigste Frage ist: Kann diese Lösung das User-Modul oder andere Module (insbesondere die im Kern) negativ beeinflussen? Und können vielleicht noch ganz andere Probleme auftauchen, die ich noch nicht bedacht habe?
Lösung B:
Ich generiere eine eigene Tabelle mit zwei Feldern, in der ich die User-ID mit einem Zeitstempel verknüpfe. Um eine Update-Möglichkeit beim Datenbank-Zugriff nutzen zu können, müsste entsprechende User-ID vorhanden sein. Aus Performance-Gründen würde ich von einer ständigen Vorab-Überprüfung absehen. Folglich müsste ich für alle bestehenden User einen Eintrag erzeugen und per hook_user in einem custom modul bei "insert" oder "delete" eines Users auch meinen User-Eintrag in meiner Tabelle erstellen oder löschen. Wenn das ganze auch noch ein komfortabel von Nomal-Anwendern benutzbares Modul werden sollte, dann wäre die Tabellen-Erzeugung (mit Einfügen vorhandener User) und die Löschung noch zu automatisieren.
Danke für Eure Aufmerksamkeit und vor allem für jeglichen Tipp in voraus,
Carsten
- Anmelden oder Registrieren um Kommentare zu schreiben
Module und Tabellen
am 10.12.2008 - 11:02 Uhr
Moin!
Solange das nicht eine Kern-Funktionalität werden soll, würde ich persönlich die Finger von den Kern-Tabellen lassen.
Also Option "B".
Das ist aus Drupal-Sicht sauberer, als die user-Tabelle zu verändern. Zu Problemen bei Option "A" dürfte es vorerst(!) eigentlich nicht kommen, es sei denn, bei einem Update wird das Schema der Tabelle geändert und zufälligerweise soll der von Dir verwendete Spaltenname für etwas anderes gebraucht werden.
Die Tabellenerzeugung und Übernahme bestehender Nutzer kannst Du ganz einfach über hook_install in der modulname.install durchführen.
hth,
Stefan
Tipp: Beachte die Verhaltensregeln des DrupalCenter.
Gibt es noch weitere Bedenken als spätere Schema-Änderung?
am 10.12.2008 - 11:59 Uhr
Hallo Stefan,
danke für Dein Feedback.
Wie ich festgestellt habe, wurde in dem Fall den das im Moment betrifft schon von einem früheren Dienstleister die User-Tabelle schon erweitert für eine individuelle Profil-Lösung. Diesbezüglich muss ich den Bereich ohnehin als mögliche Fehlerquelle im Auge behalten und mir nochmal genauer anschauen, von welcher Stelle aus diese Daten verwaltet werden.
es sei denn, bei einem Update wird das Schema der Tabelle geändert und zufälligerweise soll der von Dir verwendete Spaltenname für etwas anderes gebraucht werden
Wenn ich keine anderen Problemquellen ausfindig mache als diese, tendiere ich erstmal in diesem speziellen Fall zu Variante A um schneller eine funktionsfähige Lösung zu haben. Und ein anderes Mal kümmere ich mich dann um eine Lösung, die Variante B und die anderen bestehenden Veränderungen der User-Tabelle mit einschließt und die User-Tabelle wieder säubert.
Viele Grüße,
Carsten
--
paratio.com e.K.: Qualität-im-Internet.de
# DrupalCenter-Moderator # https://www.drupal.org/u/c-logemann
# CTO der Nodegard GmbH: Tech. Concepts | Security + Availability Operations / Wir unterstützen IT-Abteilungen, Agenturen, Freiberufler:innen
Mach drei Felder daraus
am 11.12.2008 - 21:47 Uhr
Ich generiere eine eigene Tabelle mit zwei Feldern, ...
Mach drei Felder daraus und du kannst für jeden Benutzer und jeden Node speichern, wann der Benutzer ihn das letzt mal betrachtet hat.
--
Für DB-Perfomance: Zeilen-Anzahl gleich User-Anzahl
am 17.12.2008 - 13:35 Uhr
Hallo Traxer,
Mach drei Felder daraus und du kannst für jeden Benutzer und jeden Node speichern, wann der Benutzer ihn das letzte mal betrachtet hat.
Damit würde ich zwar viel mehr Möglichkeiten haben, aber der Perfomance-Verlust wäre drastisch, weil so die Anzahl der Zeilen in der DB-Tabelle drastisch ansteigen würden. Wenn jeder User mindestens einmal jeden Node aufrufen würde, dann würde die Anzahl der Zeilen User-Anzahl mal Node-Anzahl betragen. Vor allem müsste ich (wenn ich nicht von Anfang an die Tabelle so ansteigen lassen wollte), nun die Tabelle dynamisch wachen lassen mit entsprechenden Abfragen und DB-Befehlen, die ich auch Performance-Gründen (siehe Beitrag oben) ja auch schon vermeiden wollte. Von den Aufräum-Aufageben, beim Lschen von Usern und Nodes will ich gar nicht erst anfangen.
Da vor allem die ständigen Lese-Prozesse (in meiner konkreten Aufgabe) einen Einfluß auf die Performance haben, würde ich es bevorzugen die Zeilen-Anzahl so hoch wie die Benutzer-Anzahl zu belassen. Bei steigenden Benutzer-Zahlen, könnte man sogar die Tabelle aufsplitten:
Tabelle 1: User-ID 1 bis A, Tabelle 3: User-ID A+1 bis B, Tabelle 3: User-ID B+1 bis C, ...
Dafür müsste man dann kleine IF-Abfragen nutzen, für die Unterscheidung zu welcher Gruppe der User gehört. Der Such- und Aktualisierungs-Vorgang in der jeweiligen Split-Tabelle könnte – denke ich – erheblich schneller laufen.
Für den Fall, daß man mehrere Zeitstempel benötigt, wäre eine Erhöhung der Spalten möglich. Wenn es z.B. darum geht, wann in einem bestimmten Zeitraum welche User eine Seite aufgerufen haben, macht glaube ein Anküpfen an schon bestehende Statistik-Module mehr Sinn.
Bis dann,
Carsten
--
paratio.com e.K.: Qualität-im-Internet.de
# DrupalCenter-Moderator # https://www.drupal.org/u/c-logemann
# CTO der Nodegard GmbH: Tech. Concepts | Security + Availability Operations / Wir unterstützen IT-Abteilungen, Agenturen, Freiberufler:innen