Discussion :

[Steph0]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Merci

[Richard_35]

Bonjour 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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, ...).

[Steph0]

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

[fsmrel]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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)...

[Richard_35]

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.

[fsmrel]

un trigger qui contrôle idSalarie<>IdSalarieSuperieur

Une contrainte de table (CHECK) suffira.