Discussion :

[Richard_35]

Bonjour Bakura,

Du coup c'est ta solution "non académique" qui fonctionne bien, mais j'avoue que je trouve pas ça très beau le coup de stocker tout en double dans chaque table (un pour l'utilisateur A et un pour l'utilisateur B).

==> c'est pour cela qu'elle n'est pas très académique. Sans compter que, le jour ou une discussion aura plus de deux intervenants, tu es mal... Tout est là !... si tu décides de tout bloquer à deux interlocuteurs, tu peux tout doubler...

Comment en l'état tu fais l'opération suivante : pour un utilisateur A, récupérer toutes les discussions dans lesquelles l'utilisateur A intervient, et récupérer l'identité de l'utilisateur B de chaque discussion (l'interlocuteur donc).

==> tu évoques, de nouveau, un processus. La modélisation d'une base de données ne doit pas se plier à la simplification de requête : si elle est béton, cela coule tout seul. Pour répondre à ta question :
Utilisateur A => DiscussionUtilisateur (<>A) => Utilisateur B ;
==> Discussion ==> Message.
Ce n'est qu'une solution. Un SGBD sait gérer correctement les jointures et les requêtes ne représentent que quelques lignes de code SQL.


Donc, nous sommes revenus à (lu/non lu niveau message) :

Utilisateur(id_utilisateur, nom, type (A/B), ...) ;
Discussion (id_discussion, sujet, supprimée (O/N), ...) ;
DiscussionUtilisateur (#id_discussion, #id_utilisateur, favori (O/N), ...) ;
Message (id_message, #id_discussion, #id_utilisateur, contenu, lu (O/N), ...) ;
==> à noter les relations :
Utilisateur ---(0,n)---[participe]---(2,2)--- DiscussionUtilisateur ;
Discussion ---(1,1)---[concerne]---(2,2)--- DiscussionUtilisateur.

[Bakura]

Bah écoute, merci beaucoup, je crois que c'est la solution que je vais utiliser ...