Messagesystem - Gelöschte Nachrichten

Werner S

Mitglied
Grüß euch,

bin gerade am überlegen wie das gehandhabt wird wenn in einem PN System die Nachrichten gelöscht werden.
User 1 Schreibt an User 2.
User 1 löscht die Nachricht und diese, weil eben kein SQL Eintrag mehr vorhanden ist, wird auch bei User 2 gelöscht.

Welche Lösungen gibt es dafür? Aktuell fällt mir nur ein das ich nach Absenden diese 2x in der Datenbank Speicher. Einmal für User 1 als Ausgang und 1x für User 2 als Eingang.
 

german

Aktives Mitglied
devCommunity-Experte
Ohne wirklich Ahnung davon zu haben was sich dafür durchgesetzt hat ...
Eine Alternative zum redundanten Speichern der Nachricht wäre vielleicht dass du eine Liste mit den User IDs mit ablegst, von denen die Nachricht (noch) referenziert wird. Könnten ja auch mehr als 2 sein. Wenn ein User die Nachricht löscht, löschst du nur die ID aus der Liste. Ist die Liste leer, kannst du die Nachricht aus der DB löschen. Wie gesagt, nur eine Idee ...
 

LimDul79

Neues Mitglied
Ich würde auch die Lösung @german bevorzugen. Es gibt ja ggf. mehr Informationen die man an einer Nachricht pro Person speichern will, insbesondere wenn eine Nachricht auch an mehrere Personen gehen kann. Z.b. ob die gelesen oder ungelesen ist, ist eine Information, die man pro User & Nachricht vorhalten möchte.
 

lord_haffi

Moderator
Teammitglied
Ich würde eine Tabelle für alle Messages anlegen und für jede Nachricht (unter anderem) Sender und Empfänger ID speichern. 2x etwas in einer Datenbank zu speichern ist sch**** und lässt sich eigentlich immer vermeiden. Wenn du eine Nachricht für beide löschen willst, kannst du die dann ganz einfach rausnehmen.
 

Werner S

Mitglied
Ohne wirklich Ahnung davon zu haben was sich dafür durchgesetzt hat ...
Eine Alternative zum redundanten Speichern der Nachricht wäre vielleicht dass du eine Liste mit den User IDs mit ablegst, von denen die Nachricht (noch) referenziert wird. Könnten ja auch mehr als 2 sein. Wenn ein User die Nachricht löscht, löschst du nur die ID aus der Liste. Ist die Liste leer, kannst du die Nachricht aus der DB löschen. Wie gesagt, nur eine Idee ...
Danke.
Wenn ich das jetzt richtig verstehe, so lange beschäftige ich mich noch nicht mit PHP, dann sollte es folgendermaßen aussehen.

Eine Message Tabelle in die Betreff, Nachricht, Datum und evtl. noch der Status rein kommt.
Eine Weitere Tabelle mit Message ID, sender_id, sent_to_id, seen (gelesen) und evtl. Status.

Schreibe ich eine Nachricht von User 2 an User 6. Würde in der message_user die ID der Nachricht stehen, sender_id die 2, sent_to_id die 6.
Löscht der Empfänger, in dem Fall User 6 die Nachricht, wird nur in der message_user Tabelle seine Spalte mit der ID entfernt.
Gleichzeitig wird immer beim Löschen überprüft ob noch weitere User für die Nachricht vorhanden sind, wenn nicht, auch die Nachricht aus der messages Tabelle löschen?
Will ich zb. jetzt noch den Postausgang von User 2 Anzeigen lassen wollen, brächte ich die Abfrage nur auf sender_id = 2 begrenzen?

Message:
chema::create('messages', function (Blueprint $table) {
            $table->increments('id');
            $table->text('body');
            $table->text('subject');
            $table->integer('status')->default(0);
            $table->timestamps();
           
        });

        Schema::create('messages_user', function (Blueprint $table) {
            $table->increments('id');
            $table->unsignedBigInteger('message_id');
            $table->unsignedBigInteger('sender_id');
            $table->unsignedBigInteger('sent_to_id');
            $table->dateTime('seen')->nullable();
            $table->integer('status')->default(0);
            $table->timestamps();

            $table->foreign('message_id')->references('id')->on('messages')->onDelete('cascade');
            $table->foreign('sender_id')->references('id')->on('users')->onDelete('cascade');
            $table->foreign('sent_to_id')->references('id')->on('users')->onDelete('cascade');
        });
 

lord_haffi

Moderator
Teammitglied
Das kriegste doch auch in eine Tabelle? Speicher einfach die Sender- und Empfänger-ID und den ganzen Rest aus messages_user in messages. Immerhin kann es pro Message ja immer nur einen Sender und einen Empfänger geben, da macht es keinen Sinn, das in eine extra Tabelle zu packen.
 

Werner S

Mitglied
Das kriegste doch auch in eine Tabelle? Speicher einfach die Sender- und Empfänger-ID und den ganzen Rest aus messages_user in messages. Immerhin kann es pro Message ja immer nur einen Sender und einen Empfänger geben, da macht es keinen Sinn, das in eine extra Tabelle zu packen.
Es können mehrere Empfänger angegeben werden. Diese werden aktuell in der "sent_to_id" Spalte, sofern es mehrere Empfänger gibt alle dort eingetragen, getrennt durch Komma.
Wenn aber jetzt 1 Empfänger diese Nachricht löscht, können alle anderen diese auch nicht mehr sehen.
 

lord_haffi

Moderator
Teammitglied
Ah, in dem Fall wäre es wohl eine Designfrage. Möchtest du Gruppenchats machen? D.h. erwartest du oft, dass eine Nachricht an mehrere Empfänger gehen soll? Dann ist deine Variante gut. Das Problem ist halt, dass du dann für Nachrichten mit einem Empfänger overhead hast, du kannst dir halt netto eine ID-Referenz pro Nachricht sparen und die Queries sollten schneller sein, wenn du es in eine Tabelle mit einem Empfänger machst.
Wenn es eher ein Ausnahmefall sein soll, würde man eher sowas wie nen CC bei Emails machen, d.h. die Nachricht redundant für jeden Empfänger einmal abspeichern.
Man kann auch beides machen. Dass du quasi Nachrichten mit einem Empfänger in einer Tabelle hast und Nachrichten für mehrere Empfänger, z.B. Gruppenchatnachrichten in den zwei Tabellen speicherst, wie du sie beschrieben hast.
 

Werner S

Mitglied
Ah, in dem Fall wäre es wohl eine Designfrage. Möchtest du Gruppenchats machen? D.h. erwartest du oft, dass eine Nachricht an mehrere Empfänger gehen soll? Dann ist deine Variante gut. Das Problem ist halt, dass du dann für Nachrichten mit einem Empfänger overhead hast, du kannst dir halt netto eine ID-Referenz pro Nachricht sparen und die Queries sollten schneller sein, wenn du es in eine Tabelle mit einem Empfänger machst.
Wenn es eher ein Ausnahmefall sein soll, würde man eher sowas wie nen CC bei Emails machen, d.h. die Nachricht redundant für jeden Empfänger einmal abspeichern.
Man kann auch beides machen. Dass du quasi Nachrichten mit einem Empfänger in einer Tabelle hast und Nachrichten für mehrere Empfänger, z.B. Gruppenchatnachrichten in den zwei Tabellen speicherst, wie du sie beschrieben hast.
Nein, keine Gruppenchats. Es soll ein PN System werden, wie man es aus jedem Forum kennt.
Das heist also bei einem Empfänger alles in die message Tabelle. Bei weiteren Empfänger den Haut in die message Tabelle und die anderen in die messages_user?
 
Zuletzt bearbeitet:

lord_haffi

Moderator
Teammitglied
Nicht ganz. Und es kommt drauf an, wie du es haben möchtest, dein Vorschlag, war wie gesagt schon ganz gut und wird auch der einfachste sein. Ich wollte nur Alternativen vorschlagen, je nach dem, in welche Richtung das System gehen soll.
Bei näherer Überlegung hätte ich es wohl doch so gemacht, wie du es am Anfang vorgeschlagen hast, dass Nachrichten redundant gespeichert werden. Denn ich würde intuitiv nicht davon ausgehen, dass es in Foren oft dazu kommt, dass man eine PN an mehrere Leute schicken möchte. Aber das musst du selbst entscheiden. Was ich am Ende noch meinte, so kannst du auch zwischen zwei Nachrichtentypen unterscheiden und eine Art Hybrid aus beidem basteln:
  • Eine Kombination aus zwei - nicht Chat-basiert
    • Unterscheidung von zwei Nachrichtentypen: Nachrichten mit einem und solche mit mehreren Empfängern
    • Drei Tabellen, z.B. messages_single, messages_mult, messages_mult_receiver
      • messages_single wird für Nachrichten mit einem Empfänger benutzt und beinhaltet die Empfänger-ID für jede Nachricht
      • messages_mult und messages_mult_receiver wird für Nachrichten mit mehreren Empfängern verwendet und sind so designed, wie du auch schon beschrieben hast
    • Vorteil: Perfekt für persönliche Nachrichten, die an eine oder mehrere Empfänger gehen sollen
    • Nachteil: Eventuell unnötig kompliziert, wenn einer der beiden Nachrichtentypen eher selten vorkommt.
 
Oben Unten