Relation réflexive sur une table

Bonjour,

Je me demandais si les associations réflexives étaient une mauvaise pratique en général.

Exemple classique, une table Salarié, dont chaque champ est composé de : id, nom, prénom, supérieur_hiérarchique où supérieur_hiérarchique pointe sur un autre champ de la table salarié.

La question est : cela pose-t-il problème de fonctionner ainsi, c'est à dire est-il faire une table de mariage qui gère cet appairage simple ?

Exemple pratique :

Code:

---

1 2 3 4

(id), (nom), (prenom), (superieur_hierarchique) 1, toto, toto, NULL 2, moi, moi, 1

---

Merci :)

Bonjour Steph0,

Citation:

---

Envoyé par Steph0

Je me demandais si les associations réflexives étaient une mauvaise pratique en général.

---

==> non. Mais cela dépend du contexte : des règles de gestion.

De ce point de vue, ton exemple est significatif. Les données que tu présentes reflète ces règles de gestion :

• 1 salarié reporte à 0 (NULL) ou 1 seul supérieur hiérarchique ;
• 1 supérieur hiérarchique a, sous sa responsabilité, 1 ou n salariés.

donc :

Code:

---

1 2 3 4 5

Salarie -0,1--+ | | | [Reporter à] | | +---- 1,n--+

---

donnant :

Salarie(id, nom, ...)
Salarie_Superieur(idSalarie, #IdSalarieSuperieur, ...)

une table associative, à cause du fait qu'un salarié peut ne pas avoir de supérieur hiérarchique. En effet, la possibilité qu'une clé étrangère soit nulle est dangereuse performance, quota, etc...).

A contrario, si tes règles de gestion avaient été :

• 1 salarié reporte, obligatoirement, à 1 et 1 seul supérieur hiérarchique ;
• 1 supérieur hiérarchique a, sous sa responsabilité, 1 ou n salariés.

donc :

Code:

---

1 2 3 4 5

Salarie -1,1--+ | | | [Reporter à] | | +---- 1,n--+

---

donnant :

Salarie(id, nom, #IdSalarieSuperieur,...)

N.B : la solution de la table associative peut s'avérer payante, même dans le second cas : par exemple, si ton association (réflexive) doit posséder des attributs propres (date de collaboration entre idSalarie et IdSalarieSuperieur, ...).

Bonjour,

Merci pour votre réponse détaillée. Cela répond parfaitement à ma question (il s'agit du premier cas pour moi).

Je retiens néanmoins que de manière générale une table associative reste la bonne solution, sans parler de bonnes ou mauvaises pratiques.

Merci :)

Citation:

---

Envoyé par Richard_35

Code:

---

1 2 3 4 5

Salarie -1,1--+ | | | [Reporter à] | | +---- 1,n--+

---

---

Adam est donc le fils de quelqu’un (quitte à ce qu'il soit son propre père, réflexivité oblige), et c’est parti pour une boucle infinie si on n’y prend pas garde lors de la manipulation des données (jointure récursive et toutes ces sortes de choses)... :aie:

Bonjour Fsmrel,

C'est vrai, et ma réponse était incomplète.

Salarie(id, nom, ...)
Salarie_Superieur(idSalarie, #IdSalarieSuperieur, ...)

avec, dans un premier temps, un trigger qui contrôle idSalarie<>IdSalarieSuperieur.

Dans un second temps, nous sommes dans la problématique des nomenclatures et je ne vois pas d'autre moyen que de créer un second trigger qui contrôle que les arborescences "ne se mordent pas la queue". C'est ce que font les GPAO, en général, avec les nomenclatures de produits finis.

Citation:

---

Envoyé par Richard_35

un trigger qui contrôle idSalarie<>IdSalarieSuperieur

---

Une contrainte de table (CHECK) suffira.