Ok je suis en train de changer tout ça (et tout mes script du même coup...)...
Oui je sais, j'aurais du peaufiner ma modélisation avant de coder :(
Je suis pas très très fort pour ce genre de choses...

J'ajouterais que tu y serais arrivé directement dès le départ en passant par le modèle conceptuel : en établissant ce qu'on appelle les "cardinalités".

Reprenons ton exemple :
- Un [i]rappel[/i] peut être affecté à 0 à n [i]user[/i]
- Un user peut être concerné par 0 à n [i]rappels[/i]

Donc on a une relation 0:n/0:n : le résultat est ce à quoi tu as abouti, à savoir une table relationnelle qui contient en clés étrangères les clés primaires des deux tables liées et ces deux clés étrangères forment une clé primaire composite, ce qui interdit les doublons. Et comme tu l'as fait, tu peux ajouter d'autres valeurs dans cette table relationnelle. :)

C'est adéquat !

C'est même le résultat que te donnerait une transformation d'un modèle conceptuel en modèle physique de donnée (cf. MERISE et consort)

Bonjour,
je n'ai pas trouvé de titre plus explicite (on en trouvera peut-être un ensemble ;p )
Alors voilà je vous expose mon problème:
J'ai actuellement deux tables rappels et user...
la table rappels contient une liste de rappels qui sont attribués via un champ id_user à l'utilisateur qui l'a créé...
Tout fonctionne très bien ... Maintenant je souhaiterai pouvoir "partager" un rappels avec un autre utilisateur... et la je ne pense pas qu'insérer deux rappels soit une bonne chose...
donc je me suis dit pourquoi pas faire une table de "liens" entre les deux?
Concrétement, on a:
[code]table rappels
id_rappel
etc

table "liens"
id_rappel
id_user
createur

table user
id_user
etc[/code]
J'ai volontairement réduis au strict minimum les tables...
Donc en gros lors d'un partage d'une entrée de la table rappels, j'insère plusieurs enrgistrements dans la table liens (avec en plus l'info créateur ou non pour les droits d'édition....)
Pensez-vous que ce soit faisable, performant, adapté?
Merci d'avance pour vos réponses !!