Wie sollte ich mein Datenbankschema für ein Nachrichtensystem mit Anhängen einrichten?

Question

Ich arbeite an der Erstellung eines Nachrichtensystems als Lieblingsprojekt, das die Möglichkeit von Dateianhängen beinhalten wird. Dies wird auf einer Website von mir für das interne Nachrichtensystem verwendet werden.

Eines der Merkmale dieses Systems ist, dass ich die MD5-Prüfsumme jeder hochgeladenen Datei beibehalten möchte, so dass, wenn doppelte Dateien hochgeladen werden, die beiden Links auf dieselbe Datei verweisen.

Bislang habe ich mir Folgendes ausgedacht:

Message
----------
MessageID (PK)  
SenderID (FK)  
RecipientsID (FK)  
AttachmentsID (FK)  
Subject  
MessageText  
DateSent  

Recipient  
----------  
UserID (FK)  
MessageID (FK)  

Attachment  
----------  
ID
Name
MessageID (FK)
FileID (FK)

File  
----------
ID
Checksum
LastAccessDate
AccessCount

Sie können also mehrere Nachrichten verfassen, von denen jede mehrere Anhänge enthalten kann. Aber auch, um Platz auf unserem Server zu sparen, da in meinem Anwendungsfall viele Benutzer dieselbe Datei hochladen werden, können verschiedene Anhänge auf dieselbe Datei verweisen.

Meine Frage ist, sollte die Nachrichtentabelle eine Art von RecipientsID enthalten? Oder reicht es aus, wenn meine Empfängertabelle auf die MessageID verweist?

Die gleiche Frage stellt sich für AttachmentsID in der Tabelle Message. Sollte ich eine Art von AttachmentsID haben? Oder reicht es aus, dass die Tabelle Attachment auf die MessageID verweist.

Ist es in Ordnung, wenn eine Nachricht keinen Bezug zu ihren Anhängen oder Empfängern hat, wenn sowohl Anhänge als auch Empfänger wissen, zu welcher Nachricht sie gehören? Oder sollte ich es anders machen?

Ich bin neugierig zu hören, wie erfahrene SQL-Experten dieses Schema aufbauen würden.

---

Bearbeiten: Ich möchte mehrere Empfänger und mehrere Anhänge pro Nachricht haben. Es tut mir leid, wenn das nicht klar war.

Gerade bei diesen eins-zu-vielen-Beziehungen habe ich Schwierigkeiten zu verstehen, ob ich es richtig mache.

Answer 1

Alle Ihre Fragen hängen von Ihren spezifischen Geschäftsregeln ab. Kann eine Nachricht mehr als einen Empfänger haben? Wenn ja, dann können Sie die Empfänger-ID nicht in der Nachrichtentabelle speichern, weil Sie dann nur einen Empfänger pro Nachricht speichern könnten. Denken Sie über diese Logik für jede Ihrer Situationen nach, dann wird es hoffentlich klarer.

Die Standardmethoden zur Modellierung von Beziehungen in einem RDBMS sind:

1-to-many : Die Tabelle "many" enthält die PK für die Tabelle "1". Zum Beispiel kann eine Bestellung viele Bestellzeilen haben, so dass jede Bestellzeile eine order_id hat

many-to-many : Zwischen den beiden Haupttabellen gibt es eine "Verknüpfungstabelle", die die PKs für beide Haupttabellen enthält. Diese kombinierten PKs bilden oft die PK für die Verknüpfungstabelle. In den meisten Situationen kann beispielsweise eine Nachricht an mehrere Benutzer gesendet werden, und ein Benutzer kann mehr als eine Nachricht erhalten. In diesem Fall liegt eine Many-to-many-Beziehung vor, d. h. Sie haben eine Tabelle Users (user_id, name usw.), eine Tabelle Message (message_id, message_body usw.) und eine Tabelle Message_Recipients (message_id, user_id).

1-zu-1: Aus der OO-Perspektive ist dies ähnlich wie die Unterklassenbildung. Ich könnte Gebäude in meiner Datenbank haben, die bestimmte Daten verfolgen, dann könnten zusätzlich zu diesen Daten einige Gebäude auch Häuser sein, die zusätzliche Daten verfolgen. In diesem Fall teilen sich die beiden Tabellen die gleiche PK.

Ich werde hier nicht auf Hierarchien eingehen, da sie auf verschiedene Weise modelliert werden können und das beste Modell oft von bestimmten Faktoren des Systems abhängt.

Answer 2

Hier gibt es viele gute Antworten, aber ich möchte noch etwas direkter sein:

sollte die Nachrichtentabelle etwas enthalten eine Art von Empfänger-ID enthalten?

Nein.

Oder reicht es aus, wenn mein Recipient Tabelle auf MessageID verweist?

Ja.

Die gleiche Frage für AttachmentsID auf der Tabelle Nachricht. Sollte ich eine eine Art von AttachmentsID?

Nein.

Oder reicht es aus, dass der Anhang Tabelle auf die MessageID verweist?

Ja.

Ist es in Ordnung, wenn die Botschaft keine keinen Verweis auf ihre Anhänge oder Empfänger, wenn sowohl Anhänge als auch Empfänger wissen, zu welcher Nachricht sie gehören?

Ja.

Answer 3

Actaully facebook auch verwenden ähnlich wie diese, Hier ist das Detail.

Answer 4

Sie können die Tabelle Recipients einfach ganz weglassen. Sie ist überflüssig, da die RecipientID in der Nachrichtentabelle diesen Wert enthält. Es sei denn, Sie wollen mehr als einen Empfänger haben, dann ist es notwendig, es anders zu machen.

Was die Anhänge betrifft, so ist es am besten, wenn die Anhangstabelle auf die Nachrichtentabelle verweist und nicht umgekehrt. Wenn die Nachrichtentabelle eine Anhangs-Id hat, ist sie auf einen Anhang pro Nachricht beschränkt, was wahrscheinlich gut ist, aber die Möglichkeiten einschränken könnte, wenn Sie mehrere Anhänge zulassen wollen.

Wenn Sie hingegen nur einen Anhang haben, können Sie die ID des Anhangs zusammen mit der Nachricht abrufen und die Abfragezeilen miteinander verbinden, so dass Sie alles in einer einzigen Abfrage erhalten. Das spart einige Zeilen Code.

Zusammenfassend lässt sich also sagen, dass der "minimalistische" Weg darin besteht, einen Empfänger und eine Anlage zu haben. In diesem Fall lassen Sie die Tabelle Recipient und die messageId in der Tabelle attachment fallen. Der umfangreichste Weg ist die Verwendung von mehrere Empfänger und Anhänge. In diesem Fall lassen Sie die recipientId und attachmentId in der Nachrichtentabelle fallen.

Answer 5

Je nachdem, wie Sie die Dateien speichern wollen, müssen Sie die hochgeladenen Dateinamen berücksichtigen. Ich weiß, dass es unter Windows eine maximale Pfadlänge für den Zugriff auf eine Datei gibt (wobei der Pfad den vollständigen Dateinamen und die Erweiterung enthält). Daher sollten Sie den Dateien einen beliebigen Namen geben und den tatsächlichen Dateinamen in der Dateitabelle speichern. Möglicherweise möchten Sie auch den MIME-Typ der hochgeladenen Datei berücksichtigen, damit Sie ihn über die Website zurückgeben können, wenn der Benutzer das Dokument anzeigen möchte. Entweder lesen Sie ihn anhand der Erweiterung oder etwas Ähnlichem aus und speichern ihn, oder Sie schauen einfach nach, wenn die Website dem Benutzer die Datei zum Download anbietet.