Je sais qu'il est tard pour poster, mais j'utilise le site pour ma propre référence et je voulais donc mettre une réponse ici pour que je puisse m'y référer à l'avenir aussi. J'espère que vous (et les autres) la trouverez utile.
Imaginons qu'une bande de super experts d'Einstein ait conçu notre base de données. Notre base de données super parfaite comporte 3 tables, et les relations suivantes définies entre elles :
TblA 1:M TblB
TblB 1:M TblC
Notice there is no relationship between TblA and TblC
Dans la plupart des scénarios, il est facile de naviguer dans une base de données aussi simple, mais dans les bases de données commerciales, il est généralement impossible de déterminer, au stade de la conception, toutes les utilisations et combinaisons d'utilisations possibles des données, des tables et même des bases de données entières, en particulier lorsque des systèmes sont construits et que d'autres systèmes sont intégrés ou remplacés. Ce simple fait a donné naissance à toute une industrie fondée sur les bases de données et appelée Business Intelligence. Mais je m'égare...
Dans le cas ci-dessus, la structure est si simple à comprendre qu'il est facile de voir que vous pouvez passer de TblA à B, puis à C et vice versa pour obtenir ce dont vous avez besoin. Elle met également très vaguement en évidence certains des problèmes que cela pose. Maintenant, étendez cette chaîne simple à 10, 20 ou 50 relations. Tout d'un coup, vous commencez à imaginer un besoin pour votre scénario. En termes simples, une jointure de A à C ou vice versa, ou de A à F ou de B à Z, ou autre, au fur et à mesure de l'évolution de notre système.
Il existe en effet de nombreuses façons de procéder. La plus populaire est celle mentionnée ci-dessus, qui consiste à passer par tous les liens. Le problème majeur est que c'est très lent. Et il devient progressivement plus lent au fur et à mesure que vous ajoutez des tables à la chaîne, que ces tables grandissent et que vous voulez aller plus loin.
Solution 1 : recherchez un lien commun. Il doit être présent si vous avez trouvé une raison de joindre A à C. Si ce n'est pas évident, créez une relation et joignez-la. Par exemple, pour joindre A à B à C, il doit y avoir un point commun, sinon votre jointure produira soit zéro résultat, soit un grand nombre de résultats (produit cartésien). Si vous connaissez ce point commun, il suffit d'ajouter les colonnes nécessaires à A et C et de les relier directement.
La règle pour les relations est qu'elles doivent simplement avoir une raison d'exister. Rien de plus. Si vous pouvez trouver une bonne raison de créer un lien de A à C, faites-le. Mais vous devez vous assurer que votre raison n'est pas redondante (c'est-à-dire qu'elle est déjà traitée d'une autre manière).
Maintenant, un mot d'avertissement. Il y a quelques pièges. Mais comme je ne sais pas bien les expliquer, je vous renvoie à ma source au lieu d'en parler ici. Mais n'oubliez pas que nous entrons dans le vif du sujet, et que cette vidéo sur les pièges des ventilateurs et des gouffres n'est qu'un point de départ. Vous pouvez vous inscrire sans relations. Mais je vous conseille de regarder d'abord cette vidéo car cela va au-delà de ce que la plupart des gens apprennent à l'université et bien au-delà du territoire des gars de BI et SAP. Ces gars-là, bien qu'ils sachent programmer, leur travail quotidien consiste à se spécialiser dans ce genre de choses. Comment faire en sorte que des quantités massives de données communiquent entre elles et aient un sens.
Cette vidéo est l'une des meilleures que j'ai trouvées sur le sujet. Et cela vaut la peine de regarder certaines de ses autres vidéos. J'ai beaucoup appris de lui.
