Cette référence de données circulaire pourrait-elle être mieux conçue?

Question

J'ai des données sur les couleurs. Certaines de ces couleurs se composent d'un certain nombre de couleurs combinées. Une de ces combinaisons peut théoriquement être une autre couleur combinée. Dans le cas d'une couleur combinée, j'ai besoin de définir quelques attributs sur les couleurs "enfants".

J'ai actuellement ma base de données définie comme ceci:

COLOR 
!Id 
+MultiColorGroupId 

MULTICOLOR 
    !Id 
    +MultiColorGroupId 
    +ColorId 
    +Type 

Cela peut contenir toutes les informations dont j'ai besoin d'une manière assez claire. La seule chose que je pense qui pourrait arriver est que je reçois une référence circulaire où une couleur a elle-même comme childColor. Actuellement, la seule façon d'obtenir ceci est de créer une vérification de l'insertion dans la base de données ou dans l'application. Comme la référence du cercle peut être arbitrairement profonde et que la structure actuelle peut être plutôt large, je préférerais une structure de données plus déterministe.

Y a-t-il de meilleurs moyens de définir ceci?

Answer 1

Si la profondeur peut être arbitraire, vous ne pouvez pas résoudre le problème dans la structure de données. Une chose à considérer est si c'est un problème si l'auto-référence est en fait stockée dans la base de données. Peut-être que ce devrait être au code de récupération de s'assurer qu'il ne lit pas les données à l'infini.

J'ai eu un problème similaire avec les recettes alimentaires. Il faut du yogourt pour faire du yogourt (pour choisir un exemple commun), nous avons donc dû supporter le stockage et mettre de la logique dans la récupération pour garantir qu'un ingrédient donné ne soit explosé qu'une seule fois.

Answer 2

Si vous avez une interface (autre que SQL) pour ces tables, vous pouvez facilement exclure toutes les options "illégales" des sélections disponibles. Dans le cas contraire, des déclencheurs à l'insertion et à la mise à jour ou des contraintes de vérification pourraient être utilisés.

Answer 3

Je pense que vous devez le faire dans le code, bien que je déconseille les déclencheurs - comme vous le faites remarquer le coût des déclencheurs va être bien pire qu'une relation linéaire en fonction de la complexité de vos structures.

Dans le code avec une collection c'est un problème très simple à résoudre. Vraiment vos définitions de table ne peuvent pas définir ce scénario, c'est une règle qui est une propriété de la donnée elle-même, pas la structure de stockage. En ce qui concerne la structure des données, j'ai trouvé la même structure.