Ankündigung

Einklappen
Keine Ankündigung bisher.

Struktur für Benutzeraktivitäten

Einklappen

Neue Werbung 2019

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

  • Struktur für Benutzeraktivitäten

    Hallo PHP-Freunde,

    der Titel mag merkwürdig klingen, ich nenne zu Anfang mal direkt ein Beispiel.Vielen Facebook-Nutzern wird dies sehr bekannt vorkommen:
    Hans Peter wrote "Hey, wie gehts dir?" on Tom Peter's wall.
    Ich möchte allgemein Aktivitäten (erstellen,löschen,bearbeiten) in einem Forum speichern, und zwar für Themen und Beiträge. Das sollte so aussehen:
    Hans Peter hat einen Beitrag zum Thema "PHP Fehler" geschrieben.
    Themen und Beiträge sind als Objekte realisiert

    PHP-Code:
    class Board_Topic
    {
            public 
    $Id;
            public 
    $AuthorId;
            public 
    $Title;
            ....
    }

    class 
    Board_Post
    {
            public 
    $Id;
            ....

    Wie also am besten diese drei Aktivitäten für beide Objekte speichern?

    Meine Idee ist ein neues Objekt Activity
    PHP-Code:
    class Board_Activity
    {
            public 
    $Id;
            public 
    $ObjectId//Referenz auf ...
            
    public $ObjectType// ... Post oder Topic?
            
    public $ActivityType// erstellen / bearbeiten / löschen
            
    ....

    Die MySql-Tabelle sähe dann entsprechend dem Objekt so aus (ich bleibe bei dem Beispiel von oben):
    PHP-Code:
    +----+----------+-------------+----------+--------------+
    Id ObjectId ObjectType  AuthorId ActivityType |
    +----+----------+-------------+----------+--------------+
    1  15       Board_Post  26       created      |
    +----+----------+-------------+----------+--------------+ 
    So kann ich jetzt aber z.B. gar keine Foreign-Keys benutzen, etc. Wäre evtl. doch eine Tabelle für jedes Objekt (Board_Topic, Board_Post) sinnvoll? Diese müssten dann natürlich bei der Ausgabe wieder wild durcheinander gewürfelt werden, zudem wäre es leichter diese Struktur zu erweitern (z.B. Bilder o.ä.).

    Vielleicht habt ihr ja noch eine ganz andere Idee?!
    Ich bin wie immer für jede Idee und jeden Tipp dankbar =).

    Gruß,
    Jan

  • #2
    Erstmal gratuliere ich dir zu einem sehr schönen Post.
    Sehr durchschaubar, strukturiert, sauber und ohne unwichtiges Zeug.

    Muss ja auch mal gelobt werden
    __________________________________________________ _______________


    Ich würde es ganz von dem Einsatz abhängig machen.

    Ob du ggf. später nochmals die Daten zu anderen Zwecken nutzt (Statistikerhebung o.Ä.) und sich solch ein relationales Verhältnis der Tables (ggf. später) auszahlt.

    Für solch ein simples Beispiel wie deins kann ggf. sogar keine Tabletrennung nötig sein.

    Meine Evaluierung:

    1.)
    Zwei Tabellen nutzen

    Advantage:
    - Foreign-Keys nutzbar
    - "Saubere/Strikte" Aktivitätentrennung
    - Saubere Erweiterungen möglich

    Disadvantage:
    - Höchster Performanceverlust* im Vergleich

    2.)
    Eine Tabelle nutzen mit allen Aktivitätsaufzeichnungen

    Advantage:
    - Saubere Erweiterungen möglich

    Disadvantage:
    - Nicht so sauber wie Variante 1, z.B. bei Statistikerhebungen müsste man ggf. die Query auf ein bestimmtes Feld anpassen (Beispiel: ObjectType wird BoardPost gesucht)
    - Erhöhter Performanceverlust im Vergleich*

    3.)
    Keine extra Tabelle nutzen und ein "Created on" Timestamp o.Ä. hinzufügen


    Advantage:
    - Keine extra Tables, dadurch keine extra Objekte
    - Einfache Integration durch Erweiterung der bestehenden Klasse

    Disadvantage:
    - Bei möglichen Erweiterungen zum "Akitivitätstracking" wird die Table ggf. unsauber


    *
    Ich gehe logisch davon aus, dass der Zugriff auf mehrere Tables mehr Zeit in Anspruch nimmt als den Datensatz gleichzeitig aus der gleichen Row/Table (Je nachdem was noch angefragt wird) zu fetchen.
    Bitte um sachliche Korrektur und erweiterung meines Horizontes, sollte diese Annahme falsch sein.

    Kommentar


    • #3
      Die erste Entscheidung wäre wohl, ob Du loggen willst:

      Code:
      Beitrag FooBar wurde erstellt von H-P
      Beitrag Baz wurde erstellt von Eule
      Beitrag FooBar wurde editiert von H-P
      Beitrag FooBar wurde editiert von H-P
      …
      Beitrag Baz wurde gelöscht von H-P
      oder nur die jeweils letzte Aktivität speichern willst.
      [COLOR="#F5F5FF"]--[/COLOR]
      [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
      „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
      [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
      [COLOR="#F5F5FF"]
      --[/COLOR]

      Kommentar


      • #4
        Zitat von dreamcatcher Beitrag anzeigen
        Erstmal gratuliere ich dir zu einem sehr schönen Post.
        Sehr durchschaubar, strukturiert, sauber und ohne unwichtiges Zeug.

        Muss ja auch mal gelobt werden
        Danke

        Zitat von dreamcatcher Beitrag anzeigen
        Für solch ein simples Beispiel wie deins kann ggf. sogar keine Tabletrennung nötig sein.
        Ich gebe zu, so simpel wird es nicht bleiben, ich wollte es nur nicht unnötig aufblähen, da das Prinzip eigentlich das selbe bleiben sollte, auch wenn jetzt noch ein paar mehr Objekte hinzukommen (Bilder, Kommentare, ...). Es werden am Ende zwischen vier und sechs verschiedene Objekt-Typen sein.

        Zitat von dreamcatcher Beitrag anzeigen
        1.)
        Zwei Tabellen nutzen

        Advantage:
        - Foreign-Keys nutzbar
        - "Saubere/Strikte" Aktivitätentrennung
        - Saubere Erweiterungen möglich

        Disadvantage:
        - Höchster Performanceverlust* im Vergleich
        Siehe oben, es könnten auch mehr als zwei Tabellen werden (das ging aus meinem Startpost nicht hervor), die Vorteile bleiben aber natürlich.

        Zitat von dreamcatcher Beitrag anzeigen
        3.)
        Keine extra Tabelle nutzen und ein "Created on" Timestamp o.Ä. hinzufügen


        Advantage:
        - Keine extra Tables, dadurch keine extra Objekte
        - Einfache Integration durch Erweiterung der bestehenden Klasse

        Disadvantage:
        - Bei möglichen Erweiterungen zum "Akitivitätstracking" wird die Table ggf. unsauber
        Hier wäre eine Lösch-Aktivität z.B. nicht anzeigbar.

        Nikosch, ich möchte schon loggen.

        Im moment tendiere ich zu dreamcatchers Möglichkeit 2), vielleicht kommen ja noch ein paar spannende Beiträge

        Gruß,
        Jan

        Kommentar


        • #5
          Möchtest du auch die Objekte versionieren (2) oder nur die Aktivitäten loggen (1)?

          Im Fall 1 müssen es mindestens zwei Tabellen sein.

          Bsp:

          PHP-Code:
          +----+----------+-------------+----------+--------------+ 
          Id ObjectId ObjectType  AuthorId ActivityType 
          +----+----------+-------------+----------+--------------+ 
          1  15       Board_Post  26       created      
          +----+----------+-------------+----------+--------------+  
          2  15       Board_Post  25       edited      
          +----+----------+-------------+----------+--------------+  
          3  15       Board_Post  29       edited      
          +----+----------+-------------+----------+--------------+ 
          Wenn du das alles in eine Tabelle ziehen, kannst du das entweder nicht abbilden oder wiederholst die Objektdaten, was im Falle von Texten ziemlich auf Kosten des Speichers und damit auch auf die Performance gehen würde. Nebenbei wiederspricht es den Normalisierungsregeln.

          Fall 2:

          Wenn du eh die Versionen speichern willst, kannst du es meines Erachtens auch wiederum in eine Tabelle hauen. Ob du dann jeweils die komplette Version des Textes oder nur das Delta speicherst, wäre dann erstmal zweitrangig.

          Kommentar


          • #6
            Ich verstehe nicht ganz, was du mit "versionieren" meinst.

            Texte würde ich generell nicht in dieser Tabelle speichern, die kann ich ja beim auslesen generieren.

            Gruß,
            Jan

            Kommentar


            • #7
              Naja. Also auf dein eingängliches Beispiel bezogen, meine ich damit die verschiedenen Versionen eines Posts beispielsweise.

              PHP-Code:
              +----+----------+-------------+-------------------------+----------+--------------+ 
              Id PostId   title       text                    AuthorId ActivityType 
              +----+----------+-------------+-------------------------+----------+--------------+ 
              1  15       Der Titel   Langer Text             26       created      
              +----+----------+-------------+-------------------------+----------+--------------+  
              2  15       Der Titel   Langer Text bearbeitet  25       edited       
              +----+----------+-------------+-------------------------+----------+--------------+ 
              3  15       Titel  Neu  Langer Text bearbeitet! | 25       edited       
              +----+----------+-------------+-------------------------+----------+--------------+ 
              Hängt halt stark vom Kontext ab. Bei Forumsposts machts vielleicht keinen Sinn. Bei Wikitexten oder Kollaborationen allgemein vielleicht schon eher.

              Im Endeffekt würde ich es jedoch eher in zwei Tabellen aufteilen, da z.B. bei delete oder ähnlichen Aktionen keine Änderungen im Text vermerkt werden müssten.

              Sprich: Ich bleib bei meinem ersten Statement von oben: Du brauchst zwei Tabellen.

              Kommentar


              • #8
                Okay, jetzt verstehe ich was du meinst. Das soll aber nicht der Sinn werden, ich möchte wirklich nur Aktivitäten speichern.Solange der Beitrag existiert, d.h. erstellt oder geändert wurde brauche ich ja auch nicht den Ttitel speichern (den Inhalt brauche sowieso nicht), den kann ich mir ja auch so auslesen. Sobald ein Thread / Beitrag gelöscht wird könnte ich den Titel in der DB speichern.

                Gruß,
                Jan

                Kommentar

                Lädt...
                X