Ok merci, je vais donc faire une table associative.
Ok merci, je vais donc faire une table associative.
Systématiquement je ne suis pas d'accord, mais il est vrai que je préfère souvent utiliser directement une table d'association.
Pourquoi? Parce qu'une relation 1-n est a fortiori une relation n-n. Donc techniquement la 2ème solution permet de répondre aux mêmes besoins que la relation 1-n. Par contre, en cas d'évolution des besoins métiers qui implique un changement de cardinalité, il faudra envisager une migration de données (qui aime les migration de données?) dans le premier cas alors que dans le deuxième cas, un simple changement de contrainte suffira.
En cas de contraintes très fortes sur les temps de réponses et l'espace de stockage de la base, il est peut-être souhaitable de se conformer à l'implémentation 1-n (à confirmer/valider par un DBA).
Ce n'est pas la même chose !
Si ce que tu appelles "une relation 1-n" est ce que j'appelle plutôt une "association (1,1-0,n)", c'est bien différent d'une association (0,n-0,n) ou toute autre combinaison à cardinalités maximales à n.
Pour savoir comment traiter les différents couples de cardinalités d'une association binaire, voir mon blog.
Cette discussion a surtout abordé le cas (0,1-0,n) qui est normalement un cas à table associative, contrairement au cas (1,1-0,n). Mais dire que "une relation 1-n est a fortiori une relation n-n" prête à confusion et peut induire en erreur.
La modélisation des données prend des besoins exprimés à un instant T et ne doit pas se préoccuper d'un éventuel futur plus ou moins lointain, au risque de mettre en oeuvre une solution ne répondant pas aux besoins et pouvant dégrader les performances.Par contre, en cas d'évolution des besoins métiers qui implique un changement de cardinalité, il faudra envisager une migration de données (qui aime les migration de données?)
Partager