Bonsoir Kropernic et mactwist69,
Donc nous sommes dans l'hypothèse où un client a une et une seule adresse et à une adresse on ne trouve qu'un seul client.
En premier lieu, il faut souligner qu'il s'agit d'un cas particulier qui prive le système de sa capacité à gérer tous les autres cas. En effet :
- Il sous-entend qu'aucun client ne peut avoir plusieurs adresses. Souvent dans les applications de gestion un client a une adresse de livraison et une adresse de facturation qui peuvent être différentes (et d'autres types d'adresses sont possibles).
- Il sous-entend qu'une adresse n'est affectée qu'à un client. Dans les applications de vente par correspondance, par exemple, il n'est pas rare que plusieurs membres d'une même famille, donc résidant à la même adresse, aient chacun un compte, et soient donc considérés comme des clients différents.
- Enfin, il sous-entend aussi que tout client a obligatoirement une adresse. Donc, en toute rigueur, on ne peut pas enregistrer un client dans le système s'il n'a pas d'adresse.
Mais soit, partons de cette hypothèse. La tentation est grande de "fusionner" ces deux concepts différents dans une même entité (donc au final dans une même table). On a donc l'égalité CLIENT = ADRESSE.
Mon avis est qu'il ne faut pas céder à la tentation pour deux raisons.
On bloque toute évolutivité du système vis-à-vis du rapport qu'il y a entre les deux concepts. On ne saura jamais gérer aucun des 3 cas ci-dessus. Et il y a fort à parier qu'un jour, l'un de ces cas se produira.
On élimine le concept d'Adresse en le faisant disparaître dans celui de Client. Sauf s'il s'agit d'une application "maison" (par soi-même, pour soi-même), on ne travaille jamais seul. Si ce concept Adresse est apparu au cours du recueil d'informations auprès de l'utilisateur du système, c'est que ce concept a une importance pour son métier. Il n'est donc pas judicieux de l'éliminer.
Partager