Chriz

Sagt mal, was wählt ihr als Datenbankstruktur für ein Messaging in einer Webapplikation? Sprich User X schickt User Y eine Nachricht.

Im Prinzip möchte ich ja Redundanz vermeiden, speichere die Nachricht also in einer Tabelle:

message:
id | subject | message | created

Und nun für Sender und Empfänger eine Extra/Gemeinsame-Tabelle?

sender_recipient
id | fk_message | fk_user | is_sender

Irgendwie finde ich das auch nicht so hübsch, sollte man seine Nachricht löschen, und sollten das Sender und Empfänger tun, wäre die Original-Nachricht ja noch in message. Dann müsste wieder ein Cronjob oder die Applikation selbst aufräumen.

Habt ihr da eine schöne Struktur gefunden?

__________________
"Nuschel ich?" - "Was?"

Mister Ad

McSodbrenner

Also ich mache das eigentlich so, dass ich eine User-Tabelle habe, die es ja sowieso gibt, und meine Messages-Tabelle sieht dann so aus:
id | subject | message | created | sender_id | receiver_id

Oder habe ich deine Frage falsch verstanden? Es kann ja nicht mehrere Sender oder Empfänger pro Nachricht geben, oder? Also 1/n.

__________________
http://mcsodbrenner.blogspot.com/
Serpent PHP Template Engine: http://code.google.com/p/serpent-php-template-engine/

Young Jedi

Bei der von dir beschriebenen Datenbankstruktur ist zum ersten ein Löschen nur von Seiten des Absenders/Empfängers ohne, dass es auf der anderen Seite mit gelöscht wird nicht möglich und außerdem werden zum Beispiel bei einer "Rundschrift" von z.B. den Administrator an die Benutzer eine Unzahl an Datenbankeinträgen erstellt, die eigentlich nicht nötig ist.

@Chriz: Ich denke, deine Datenbankstruktur ist so schon ok, oder besser gesagt würde mir auf Anhieb keine bessere einfallen. Ist es nicht möglich, dass du bei dem Löschen der Nachricht nicht einfach abfragen kannst, ob nicht bereits beide Benutzer diese gelöscht haben und in dem Fall die Nachricht auch aus der 1. Tabelle zu löschen... klingt zwar jetzt etwas umständlich, ist aber eigentlich gar nicht so unperformant (da es ja nicht allzu oft vorkommt, dass man die Nachricht löscht)

__________________
http://tippsgegenlangeweile.de

Chriz

@McSodbrenner:
Da liegt das Problem, das auch schon angesprochen wurde: Mehrfach-Sendung muss möglich sein, und natürlich muss die Nachricht jeder Empfänger individuell löschen können.

@YoungJedi:
Ja, ich dachte nur, vielleicht hat hier jemand das ultimative Strukturformat. Wie wird das hier im phpBB denn gelöst?

__________________
"Nuschel ich?" - "Was?"

dr.e.

Dann würde ich Empfänger über Assoziationen zuordnen. Löscht diese ein Empfänger, so wird nur die Assoziation gelöscht. Wird die letzte Assoziation gelöscht, so wird auch die Nachricht inkl. der Komposition zum Container gelöscht. Wichtig ist dabei noch, dass die Assoziation qualifiziert ist (=Zurdonung, in welchem Ordner die Nachricht ist). Das könnte man aber auch über mehrfache Beziehungen zu Status-Objekten erledigen.

Beispiel:
Eine Nachricht hat 3 Empfänger und liegt im Gesendet-Ordner eines Benutzers, ist jedoch von nur einem Empfänger bereits gelesen. Für die unterschiedlichen Ordner-Zuordnungen und Status gibt es folgende Objekte:

• Gesendet-Ordner: echter Ordner, dient zur Kategorisierung der Anzeige
• Gelesen-Status: existiert eine Assoziation, so ist die Nachricht gelesen
• Benutzer: Objekt des Benutzes

Der Status des oben beschriebenen Szenarios kann durch folgende Assoziationen abgebildet werden:

• Benutzer-zu-Nachricht: Bezeichnet Benutzer als Empfänger
• Gelesen-zu-Nachricht: bezeichnet die Nachricht für einen Benutzer als gelesen

Klingt kompliziert, ist es auch, willst du eine Nachricht nur einmal im System halten, sollte das aber eine wirksame Möglichkeit sein. Die aufgezeigten Fälle sind dabei sicher nur ein Teil, man müsste das also zunächst zu Ende diskutieren.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Chriz

Den Gelesen-Status löse ich momentan über ein DATETIME Feld, in dem NULL (= ungelesen) steht.

Das heißt letztlich muss mir die Applikation den Message-Datensatz löschen, wenn keine Beziehungen mehr vorhanden sind?! Kann man das in der Datenbank dann nur mit Triggern lösen nehme ich an?

__________________
"Nuschel ich?" - "Was?"

meGa

Hallo, du könntest es mit zwei Tabellen lösen. Eine speichert nur die Nachrichten, also z.B. so:

id | time | subject | message

Dann machst du eine Weitere, wo die Verbindungen angegeben werden, z.B. so:

id | sender_id | empfeanger_id

Somit kannst du meheren eine Nachricht schicken und wenn einer sie löst ist der andere unabhänig davon. Was meint ihr?

Young Jedi

*hust*
message:
id | subject | message | created

sender_recipient
id | fk_message | fk_user | is_sender

ist -genau- das, nur dass es noch etwas besser mit is_sender gelöst wurde

__________________
http://tippsgegenlangeweile.de

dr.e.

Hallo Chriz,

Ja. Mit Triggern würde ich das nicht lösen, sondern in der Applikationslogik beschreiben. Grundsätzlich müsste man sich vielleicht im Gesamt-Kontext nochmals Gedanken über die Zugehörigkeit der Nachricht machen. Vielleicht ergibt sich daraus sogar nochmal eine Vereinfachung.

Mit zig Flags in der Datenbank - wie hier auch vorgestellt - würde ich nicht arbeiten, da die Applikationslogik sehr schnell unübersichtlich wird und vor allem weg von der Objektorientierung geht!

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

meGa

Ob man deins nun als besser ansieht, würde ich sagen kann man sich drüber streiten.