Je modélise un scénario de base de données mais je ne comprends pas correctement comment y parvenir. Le scénario est un utilisateur capable de faire des plaintes en ligne. Il entre dans le titre et la description de la plainte et soumet l'information. L'administrateur du site peut voir toutes les plaintes d'utilisateurs et répondre. J'ai donc un scénario comme celui-ci: et en termes de relations il y a: Ce scénario devrait fonctionner pour cet exemple: L'utilisateur soumet une plainte, l'administrateur reçoit la plainte et soumet la réponse et l'utilisateur peut vérifier la réponse. problème: Cependant, l'utilisateur Ensuite, a accès à la réponse administratrice et l'utilisateur doit pouvoir répondre à cette réponse administratrice similaire à un scénario de discussion dans lequel l'administrateur aura également accès au nouveau message de plainte de l'utilisateur. Mais je ne comprends pas comment le modèle DB devrait être de prendre en charge ce scénario où peut exister plusieurs messages entre l'utilisateur et l'administrateur relatives à une plainte. Savez-vous comment cela peut être atteint?
3 Réponses :
On dirait que vous voulez une table séparée pour les messages. On dirait que les messages sont spécifiques à une plainte, vous pouvez donc avoir:
EmpetinsID
-
plainpide Références Plaintes (plainte)
-
BYUSERID non-NULL lorsque l'utilisateur initie le message
-
BYADMINID NON-NULL lorsque l'administrateur initie le message
-
messagetext
Vous devrez peut-être penser à des scénarios compliqués. Peut-être que plusieurs administrateurs travaillent une plainte (que le modèle ci-dessus prend en charge). Ou peut-être que de multiples plaintes sont combinées dans un flux de messages (que le modèle ci-dessus ne prend pas en charge).
Bons points. Cependant, je ne stockerais pas l'administrateur et l'ID utilisateur. Juste l'ID utilisateur de l'utilisateur, qui envoie le message. En tant que plainte contenant un utilisateur et un administrateur unique, il n'est pas nécessaire de stocker cela à chaque fois.
@davidev. . . C'est très raisonnable. Je quittais le modèle de données ouvert à plus d'interactions, au cas où l'on souhaitait.
Vous avez plusieurs choix pour résoudre ce problème.
Une option serait de restructurer votre entité conforme à la fabrication d'une plainte initiale et d'une réponse également en ajoutant une référence à une instance précédente de la conformité. Cette référence peut être vide en cas de plainte initiale ou contient l'ID d'une réponse / plainte précédente. L'attribut de réponse serait obsolète dans ce cas.
Votre modélisation DB est déjà très calme.
plainte: id, titre, description, réponse, statut (en attente de résolution, résolue), iduseur, idadmin p> BlockQuote>
Comme vous l'avez expliqué, une plainte a une clé étrangère pour l'utilisateur et l'administrateur. Maintenant que chaque plainte a une pièce d'identité unique en tant que clé primaire, vous pouvez identifier toutes les plaintes. P>
Je suggérerais de créer une autre table pour les messages p>
xxx pré> chaque message Appartient à une plainte, mais une plainte peut avoir plusieurs messages, ce qui est totalement correct. Si vous souhaitez afficher maintenant tous les messages d'une plainte, le WHEAT est l'administrateur ou l'utilisateur, vous sélectionnez tous vos messages à partir de l'ID de plainte spécifique. P>
SELECT message FROM message m WHERE m.complaintId = 1 ORDER BY m.date
Tout comme une note latérale: veuillez n'utiliser pas des balises dans votre poste qui ne sont pas pertinentes. Cette question n'est pas liée à PHP ou à MySQL après tout