Je vais prendre cette question du point de vue de modélisation.
Tant que vous n'ajoutez pas de relations qui n'y sont pas, vous êtes en sécurité. Si vous les ajoutez, vous obtenez moins d'intégrité dans les données (car il y a une redondance) et un code plus étroitement couplé.
Le problème avec les références circulaires, en particulier, est que je n’ai pas vu de cas où elles seraient réellement nécessaires, sauf une - référence personnelle. Si vous modélisez des arbres ou des graphiques, vous en avez besoin et tout va bien, car la référence à soi est sans danger du point de vue de la qualité du code (aucune dépendance ajoutée).
Je pense qu'au moment où vous commencez à avoir besoin d'une référence non auto-référente, vous devez immédiatement demander si vous ne pouvez pas le modéliser sous forme de graphique (réduire les entités multiples en un seul nœud). Peut-être existe-t-il un cas entre deux références où vous faites une référence circulaire, mais la modélisation sous forme de graphique n'est pas appropriée, mais j'en doute fortement.
Les gens risquent de penser qu’ils ont besoin d’une référence circulaire, mais ce n’est pas le cas. Le cas le plus commun est "Le cas un-de-plusieurs". Par exemple, vous avez un client avec plusieurs adresses parmi lesquelles une doit être marquée comme adresse principale. Il est très tentant de modéliser cette situation sous la forme de deux relations distinctes has_address et is_primary_address_of mais ce n'est pas correct. La raison en est qu'être l'adresse principale n'est pas une relation séparée entre les utilisateurs et les adresses, mais bien un attribut de la relation à l' adresse. Pourquoi donc? Parce que son domaine est limité aux adresses de l'utilisateur et non à toutes les adresses existantes. Vous choisissez l'un des liens et le marquez comme le plus fort (primaire).
(Parlons maintenant des bases de données) Beaucoup de gens optent pour la solution à deux relations parce qu'ils comprennent que «primaire» est un pointeur unique et qu'une clé étrangère est en quelque sorte un pointeur. Donc, la clé étrangère devrait être la chose à utiliser, non? Faux. Les clés étrangères représentent des relations mais "primaire" n'est pas une relation. C'est un cas dégénéré de commande où un élément est avant tout et le reste n'est pas commandé. Si vous aviez besoin de modéliser un ordre total, vous le considéreriez bien sûr comme un attribut de relation, car il n'y a pas d'autre choix. Mais au moment où vous le dégénérez, il existe un choix et un choix horrible: modéliser quelque chose qui n'est pas une relation en tant que relation. Alors voilà, la redondance des relations n’est certainement pas à sous-estimer.
Donc, je ne laisserais pas une référence circulaire se produire à moins qu'il soit absolument clair que cela vient de la chose que je modélise.
(note: ceci est légèrement biaisé par la conception de la base de données mais je parierais que c'est assez applicable à d'autres domaines aussi)