On trouve parfois cette recommandation qui consiste à éviter les
colonnes de clé étrangère pouvant contenir des NULL (au profit d'une
table d'association je suppose). Ici encore récemment.
Pourquoi ? Quels sont les avantages et inconvénients des deux
approches ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Ph. B.
Yliur a écrit :
Bonjour
On trouve parfois cette recommandation qui consiste à éviter les colonnes de clé étrangère pouvant contenir des NULL (au profit d'une table d'association je suppose). Ici encore récemment.
Pourquoi ? Quels sont les avantages et inconvénients des deux approches ?
Yliur
Bonjour,
Pour une table d'association, je suis d'accord, pour le reste non. Je m'explique avec 3 exemples :
1-a) "Un employé peut avoir un seul responsable direct" Ce qui se modélise par une table : EMPLOYE(EMP_ID, EMP_NOM, EMP_ID_RESP)
La clé étrangère EMP_ID_RESP qui est réflexive peut être indéfinie (NULL).
1-b) "Un téléphone cellulaire est affecté à un seul employé" Ce qui se modélise par 2 tables : EMPLOYE(EMP_ID, EMP_NOM) CELLULAIRE(CEL_ID, CEL_IMEI, EMP_ID_AFF)
La clé étrangère EMP_ID_AFF peut être indéfinie si le téléphone est en stock et non attribué.
2) "Une personne peut posséder un ou plusieurs appartements" Ce qui se modélise par 2 tables et 1 table d'association : PERSONNE(PRS_ID, PRS_NOM) APPARTEMENT(APT_ID, APT_INTITULE) POSSEDE(PRS_ID, APT_ID)
Dans ce cas, il est aberrant d'avoir une des clés étrangères APT_ID ou PRS_ID indéfinies. Dans le cas contraire, on aurait dans la table des lignes de ce type : POSSEDE(5, NULL) ou POSSEDE(NULL, 10). La présence de ces informations n'apporte rien à la base de données, si ce n'est occuper de l'espace. La recommandation prend dans ce cas tout son sens. -- Philippe.
Yliur a écrit :
Bonjour
On trouve parfois cette recommandation qui consiste à éviter les
colonnes de clé étrangère pouvant contenir des NULL (au profit d'une
table d'association je suppose). Ici encore récemment.
Pourquoi ? Quels sont les avantages et inconvénients des deux
approches ?
Yliur
Bonjour,
Pour une table d'association, je suis d'accord, pour le reste non.
Je m'explique avec 3 exemples :
1-a) "Un employé peut avoir un seul responsable direct"
Ce qui se modélise par une table :
EMPLOYE(EMP_ID, EMP_NOM, EMP_ID_RESP)
La clé étrangère EMP_ID_RESP qui est réflexive peut être indéfinie (NULL).
1-b) "Un téléphone cellulaire est affecté à un seul employé"
Ce qui se modélise par 2 tables :
EMPLOYE(EMP_ID, EMP_NOM)
CELLULAIRE(CEL_ID, CEL_IMEI, EMP_ID_AFF)
La clé étrangère EMP_ID_AFF peut être indéfinie si le téléphone est en
stock et non attribué.
2) "Une personne peut posséder un ou plusieurs appartements"
Ce qui se modélise par 2 tables et 1 table d'association :
PERSONNE(PRS_ID, PRS_NOM)
APPARTEMENT(APT_ID, APT_INTITULE)
POSSEDE(PRS_ID, APT_ID)
Dans ce cas, il est aberrant d'avoir une des clés étrangères APT_ID ou
PRS_ID indéfinies. Dans le cas contraire, on aurait dans la table des
lignes de ce type : POSSEDE(5, NULL) ou POSSEDE(NULL, 10). La présence
de ces informations n'apporte rien à la base de données, si ce n'est
occuper de l'espace. La recommandation prend dans ce cas tout son sens.
--
Philippe.
On trouve parfois cette recommandation qui consiste à éviter les colonnes de clé étrangère pouvant contenir des NULL (au profit d'une table d'association je suppose). Ici encore récemment.
Pourquoi ? Quels sont les avantages et inconvénients des deux approches ?
Yliur
Bonjour,
Pour une table d'association, je suis d'accord, pour le reste non. Je m'explique avec 3 exemples :
1-a) "Un employé peut avoir un seul responsable direct" Ce qui se modélise par une table : EMPLOYE(EMP_ID, EMP_NOM, EMP_ID_RESP)
La clé étrangère EMP_ID_RESP qui est réflexive peut être indéfinie (NULL).
1-b) "Un téléphone cellulaire est affecté à un seul employé" Ce qui se modélise par 2 tables : EMPLOYE(EMP_ID, EMP_NOM) CELLULAIRE(CEL_ID, CEL_IMEI, EMP_ID_AFF)
La clé étrangère EMP_ID_AFF peut être indéfinie si le téléphone est en stock et non attribué.
2) "Une personne peut posséder un ou plusieurs appartements" Ce qui se modélise par 2 tables et 1 table d'association : PERSONNE(PRS_ID, PRS_NOM) APPARTEMENT(APT_ID, APT_INTITULE) POSSEDE(PRS_ID, APT_ID)
Dans ce cas, il est aberrant d'avoir une des clés étrangères APT_ID ou PRS_ID indéfinies. Dans le cas contraire, on aurait dans la table des lignes de ce type : POSSEDE(5, NULL) ou POSSEDE(NULL, 10). La présence de ces informations n'apporte rien à la base de données, si ce n'est occuper de l'espace. La recommandation prend dans ce cas tout son sens. -- Philippe.
