ce que tu veux implementer est une relation d'héritage, en effet, deux types d'entités de ton modèle, à savoir 'association' et 'commerce' ont en commun une caractéristique (celle de pouvoir être organisateur pour une manifestation). C'est dans ce genre de situation que l'héritage intervient.
tu fais une table 'personne' ou 'interlocuteur' ou ce que tu veux
dedans tu comptabilises tous les interlocuteurs (commerces et associations), via un id, et, si tu veux, un nom. Ensuite, dans tes tables association et commerce, tu utilises comme id pour les entrées leur id de la table 'interlocuteur'.
Dans ta table manifestation, la clé organisateur se réfère à la clé primaire de la table 'interlocuteur'.
Pour savoir s'il s'agit d'un commerce ou d'une association, tu cherches si l'id est présent dans la table commerce ou dans la table association.
Ma solution a de nombreux problèmes : impossible de s'assurer qu'un élément présent dans 'interlocuteur' est présent dans l'une des deux tables ? Ni de s'assurer qu'un élément présent dans association n'est pas présent dans commerce.
# une solution parmi d'autres
Posté par Nap . En réponse au message Relations entre table dans MySQL. Évalué à 2.
tu fais une table 'personne' ou 'interlocuteur' ou ce que tu veux
dedans tu comptabilises tous les interlocuteurs (commerces et associations), via un id, et, si tu veux, un nom. Ensuite, dans tes tables association et commerce, tu utilises comme id pour les entrées leur id de la table 'interlocuteur'.
Dans ta table manifestation, la clé organisateur se réfère à la clé primaire de la table 'interlocuteur'.
Pour savoir s'il s'agit d'un commerce ou d'une association, tu cherches si l'id est présent dans la table commerce ou dans la table association.
Ma solution a de nombreux problèmes : impossible de s'assurer qu'un élément présent dans 'interlocuteur' est présent dans l'une des deux tables ? Ni de s'assurer qu'un élément présent dans association n'est pas présent dans commerce.
C'est les limites de MySQL...