SQL Design bei PM System für ein oder mehrere Benutzer mit Threading Ansicht?

[ap1]

Hey Leute

Wie geht das am besten:
Es soll ein PM System geben, was folgendes können soll:

- zwischen zwei oder wahlweise mehreren Benutzern können Nachrichten geschrieben werden
- alle sollen die Nachrichten lesen und Nachverfolgen können aber nicht wie etwa bei alten Handys sondern wie etwa hier im Forum als "Thread"
- wenn sich auch nur zwei personen unterhalten soll ebenso diese Ansicht verfügbar sein...

wie geht das? ich habe probleme beim Datenbankdesign..

[wolf29]

Normalisierung (Datenbank) – Wikipedia

Wolf29

[ap1]

Normalisierung (Datenbank) – Wikipedia

Wolf29

Ich habe nun anhand deines Artikels, dankeschön hierfür, ein Muster entworfen.

= Threads =
thread_id (int,255,auto_inc) | betreff (varchar,255)

= Recipients = 
id (int,255,auto_inc) | thread_id (int,255) | user_id (int,255)

= Contents =
id (int,255,auto_inc)| thread_id | content (longtext)

Ist das für mein Anliegen komplett daneben?

[ChrisB]

Ist das für mein Anliegen komplett daneben?

Nein, das sieht als Ansatz schon mal brauchbar aus*.

Bei Threads und Contents (letzteres würde ich vllt. eher Entries nennen) solltest du noch ein Erstellungsdatum mit reinbringen, um danach sortieren zu können (denn eine ID dient ausschließlich der Identifikation eines Datensatz, für Sortierungen sollte man die nicht heranziehen).

Den Ersteller eines neuen Thread willst du dann natürlich sofort in der Recipients-Tabelle mit eintragen - sonst darf der nachher selber die Diskussion nicht mehr lesen.

Ob zwischen Thread-Erstellern und Antwortern unterschieden werden muss (bspw. mittels eines zusätzlichen Kennzeichens in der Recipients-Tabelle), wäre noch zu überlegen. Per se erst mal nicht - denn beide erstellen einen neuen Entry zu einem Thread, nur der eine halt initial zur Eröffnung des Threads, die anderen als Antworter/Mitdiskutierer.
Interessant wird das aber ggf. wenn es darum geht, wer was Löschen darf - Thread bzw. Entry. Wobei vorher zu klären wäre, ob überhaupt jemand (abgesehen vom Admin, bei Regelverstößen) löschen darf - wenn ein Diskussionsteilnehmer seine Beiträge nachträglich löschen darf, kann das u.U. den Sinn des kompletten Threads entstellen, wenn nachfolgende Antworter bereits Bezug darauf genommen haben.


Und dann wäre noch zu klären, wie du die Darstellung aufbauen willst - flach, wie in einem Board; oder als Baum, wie in einem Forum. Für letzteres müsstest du dir zu jedem Eintrag auch noch eine Parent-ID merken.


* Wobei du mit dem Datentyp int, 255, wenn du damit sowas wie MySQLs unsigned TINYINT meinst, natürlich nicht weit kommst - schon bei 20 Threads mit jeweils 13 Beiträgen sprengst du dir da den Wertebereich der ID in deiner Contents-Tabelle. Da solltest du also etwas großzügiger sein bei der Wahl des Datentyps.

[ap1]

Vorne weg vielen Dank. Klasse antwort!

Nein, das sieht als Ansatz schon mal brauchbar aus*.

* Wobei du mit dem Datentyp int, 255, wenn du damit sowas wie MySQLs unsigned TINYINT meinst, natürlich nicht weit kommst - schon bei 20 Threads mit jeweils 13 Beiträgen sprengst du dir da den Wertebereich der ID in deiner Contents-Tabelle. Da solltest du also etwas großzügiger sein bei der Wahl des Datentyps.

Das mit dem Datentyp int, 255 war vermutlich missverständlich in der Auflistung. Ich meinte ein int mit 255 Stellen länge (falls möglich?).

Bei Threads und Contents (letzteres würde ich vllt. eher Entries nennen) solltest du noch ein Erstellungsdatum mit reinbringen, um danach sortieren zu können (denn eine ID dient ausschließlich der Identifikation eines Datensatz, für Sortierungen sollte man die nicht heranziehen).

Es wäre sinnvoll nur bei Contents (oder ab hier Entries) das Erstellungsdatum einzufügen, denn der erster Entry ist schließlich auch Thread beginn - zumindest sehe ich das so?

Den Ersteller eines neuen Thread willst du dann natürlich sofort in der Recipients-Tabelle mit eintragen - sonst darf der nachher selber die Diskussion nicht mehr lesen.

Danke. Das hätte ich in der Tat vergessen!

Ob zwischen Thread-Erstellern und Antwortern unterschieden werden muss (bspw. mittels eines zusätzlichen Kennzeichens in der Recipients-Tabelle), wäre noch zu überlegen. Per se erst mal nicht - denn beide erstellen einen neuen Entry zu einem Thread, nur der eine halt initial zur Eröffnung des Threads, die anderen als Antworter/Mitdiskutierer.

Sehe ich genauso, deshalb lasse ich die Kennzeichnung eines Erstellers weg.

Interessant wird das aber ggf. wenn es darum geht, wer was Löschen darf - Thread bzw. Entry. Wobei vorher zu klären wäre, ob überhaupt jemand (abgesehen vom Admin, bei Regelverstößen) löschen darf - wenn ein Diskussionsteilnehmer seine Beiträge nachträglich löschen darf, kann das u.U. den Sinn des kompletten Threads entstellen, wenn nachfolgende Antworter bereits Bezug darauf genommen haben.

Aus diesem Grund niemand , schließlich kann man das bei einer SMS oder Email auch nicht, und letztlich soll das Message System nicht mehr als Nachrichten übermitteln. Diese allerdings in....

Und dann wäre noch zu klären, wie du die Darstellung aufbauen willst - flach, wie in einem Board; oder als Baum, wie in einem Forum. Für letzteres müsstest du dir zu jedem Eintrag auch noch eine Parent-ID merken.

... Brettansicht darstellen. Denn ich möchte einen flüssigen Verlauf, um Nachrichten von oben nach unten lesen zu können!

Vielen vielen Dank soweit, sehr große Hilfe!

[ChrisB]

Das mit dem Datentyp int, 255 war vermutlich missverständlich in der Auflistung. Ich meinte ein int mit 255 Stellen länge (falls möglich?).

Jein, man betrachtet dabei immer den abbildbaren Wertebereich, nicht die Anzahl „Stellen“ (Ziffern).

MySQL :: MySQL 5.1 Reference Manual :: 10.2 Numeric Types gibt dir einen Überblick über den Wertebereich der nummerischen Datentypen - mit dem von unsigned INT dürftest du erst mal „gut bedient“ sein.

Es wäre sinnvoll nur bei Contents (oder ab hier Entries) das Erstellungsdatum einzufügen, denn der erster Entry ist schließlich auch Thread beginn - zumindest sehe ich das so?

Vielleicht möchtest du aber auch mal eine Liste aller Threads, die ein Nutzer sich anschauen darf, ausgeben - zum Sortieren dieser wäre es dann ggf. hilfreich, wenn du den Erstellungszeitpunkt schon in der Threads-Tabelle hast, und nicht noch die Entries-Tabelle per JOIN hinzunehmen musst.

Vielen vielen Dank soweit, sehr große Hilfe!

Bei weiteren Fragen/Problemen - einfach noch mal melden.