Tables d'intersection multiples vs jointures multiples

Question

J'ai une relation hiérarchique entre mes tables, les enfants ayant des clés étrangères renvoyant à leurs identifiants parents (en supposant que idc'est la clé primaire pour chaque table):

Departmenta plusieurs Category Groups
Category Groupa beaucoup Category(-ies)
Categorya beaucoup Sub-Category(-ies)
Sub-Categorya beaucoup de Attributes.

Maintenant, toutes ces entités à l'exception de Attributes sont facultatives, ce qui signifie que si je ne sélectionne rien sur mon interface utilisateur basée sur la liste déroulante en cascade hiérarchique, je dois afficher les Attributes qui appartiennent à tous les Departments, si je ne sélectionne que un, Departmentje dois afficher les Attributes qui appartiennent à tous les Category Groups appartenant à cela Departmentet ainsi de suite.

De toute évidence, une option pour l'implémenter est de faire une jointure interne entre toutes les tables auxquelles accéder Attribute. Par exemple, si rien n'est sélectionné, ce sera:
Departmentjointure Category Group
interne jointure Category
interne jointure Sub-Category
interne jointure interne Attribute
pour afficher tous les attributs appartenant à tous les départements.

L'autre pensée dans ma tête est d'avoir intersection / relation table de correspondance (s) -
DepartmentAttributeRelationqui a les clés étrangères Departmentet Attribute,
CategoryGroupAttributeRelationqui a les clés étrangères CategoryGroupet Attributeet ainsi de suite.
Cela permettra à la recherche directe d'accéder au Attributes donné n'importe quelle entité.

Ma question est la suivante: y a-t-il des inconvénients à la deuxième approche ci-dessus ou y a-t-il de meilleures approches pour résoudre ce problème?

Answer 1

Quel est le problème avec la jointure interne? Créez une vue pour ne plus jamais avoir à voir ou à écrire la vilaine requête multi-jointure.

Le premier et le plus important inconvénient de l'alternative est que vous pouvez avoir des incohérences, c'est-à-dire que vous pouvez avoir des données dans ces "tables de jointure" qui pourraient potentiellement se contredire, c'est-à-dire que des anomalies d'insertion sont possibles. Vous auriez besoin d'écrire du code pour éviter que ces anomalies ne se produisent.

Gardez à l'esprit, cependant, que parfois, lorsque l'on croit qu'une hiérarchie sera pour toujours à beaucoup, disons, 4 niveaux de profondeur, alors une exigence survient lorsqu'une sous-sous-catégorie est nécessaire et que la conception de la hiérarchie à niveau fixe se rompt. Une solution à l'épreuve du temps où il peut y avoir une profondeur inconnue de niveaux de hiérarchie et seuls les éléments «feuille» peuvent avoir des attributs est une question d'une autre question et d'une autre réponse.