Proper-Datenbankmodell für ein Benutzer-Feedback-System (ein interessanter Fall)

Ich entwickle eine Anwendung mit PHP und Yii Framework. Ich habe über die am besten geeignete Datenbankstruktur für die gegebene Funktionalität nachgedacht und habe mir Folgendes ausgedacht. Trotzdem bin ich mir nicht sicher, ob das so ist, also habe ich beschlossen, die Community zu fragen.

App Beschreibung:

Registrierte Benutzer können an einer Veranstaltung teilnehmen. Jede Veranstaltung kann eine unbegrenzte Anzahl von Benutzern haben, die als "Teilnehmer der Veranstaltung" bezeichnet werden.

Nach Ablauf der Veranstaltung kann jeder Teilnehmer eine Bewertung zu jedem anderen Teilnehmer derselben Veranstaltung abgeben.

Datenbankstruktur:

Da jede Veranstaltung eine unbegrenzte Anzahl von Benutzern haben kann und Benutzer an einer unbegrenzten Anzahl von Veranstaltungen teilnehmen können, habe ich eine Tabelle "Teilnehmer" erstellt, in der die Viele-zu-Viele-Beziehung aufgelöst wird.

Andere Tabellen sind selbsterklärend.

Und hier ist das Wichtigste:

Jeder Teilnehmer einer Veranstaltung kann die maximale Anzahl von Rückmeldungen haben, die der Anzahl von Teilnehmern derselben Veranstaltung ohne den angegebenen Teilnehmer entspricht (Beispiel: Wenn es 5 Teilnehmer der Veranstaltung gibt, kann der angegebene Teilnehmer 4 Rückmeldungen von Teilnehmern der Veranstaltung erhalten gleiche Veranstaltung).

Lassen Sie mich betonen, dass nur Teilnehmer derselben Veranstaltung ein (und nur ein) Feedback zu dem angegebenen Teilnehmer hinterlassen können.

m Folgenden sind die Schritte aufgeführt, die ich unternommen habe, um die Integrität der Datenbank sicherzustelle

Ich habe die Spalte "id" in der Tabelle "Participant" erstellt, um jedem Benutzer, der an einem bestimmten Ereignis teilnimmt, eine eindeutige ID zu geben. Diese ID ist zusammengesetzt (user_id und practice_id sind miteinander verknüpft). Die Teilnehmer-ID des Benutzers 23, der an Ereignis 14 teilgenommen hat, wäre also 14-23.

Sie fragen sich vielleicht, warum ich beschlossen habe, eine separate Spalte mit dieser ID zu erstellen, anstatt einfach den Primärschlüssel wie folgt zu definieren:

PRIMARY KEY (user_id, event_id)

Weiter lesen

Wenn die Veranstaltung beendet ist, kann jeder Teilnehmer eine Bewertung zu den anderen abgeben. Diese Teilnehmer-ID kann nun durch die Fremdschlüssel "sender_id" und "recipient_id" in der Feedback-Tabelle referenziert werden.

Weiterhin wird der Primärschlüssel der Rückmeldungstabelle auch durch Kombinieren von "sender_id" und "recipient_id" gebildet, wenn also der Benutzer 23 eine Rückmeldung über den Benutzer 45 hinterlassen möchte (beide nahmen an dem Ereignis 71 teil), Der Primärschlüssel für das Feedback wäre: 71-45-71-23.

Dieser Ansatz ermöglicht es uns, auf Datenbankebene sicherzustellen, dass kein Teilnehmer zweimal ein Feedback zu demselben Teilnehmer hinterlässt und ein Benutzer nicht zweimal an derselben Veranstaltung teilnehmen kann.

Fragen

Hat dieser Ansatz das Recht zu existieren?Was sind die Profis und andere, bessere Möglichkeiten, diese Funktionalität zu nutzen?Kann ich die Primärschlüssel basierend auf den Werten der anderen Spalten automatisch beim Einfügen eines Datensatzes generieren?

Antworten auf die Frage(2)

Ihre Antwort auf die Frage