C'est bien ce qui me semblait... C'est au développement de se plier à la modélisation, et non l'inverse.
Effectivement, il est possible de créer :
Utilisateur -0,1---[Possèder]---(1,1)- Utilisateur_AttributsAnnexes
donnant :
Utilisateur(IdUtilisateur, Nom, [attributs que tu considères comme souvent renseignés])
Utilisateur_AttributsAnnexes(#IdUtilisateur, [attributs que tu considères comme pas souvent renseignés])
Mais, la frontière entre "souvent renseignés" et "pas souvent renseignés" est floue. Au moindre besoin d'un seul champ dans la seconde table, tu ramèneras l'ensemble des champs.
A moins de créer une autre table des "attributs moyennement renseignés"... d'où une gestion dangereuse des niveaux de renseignements... re .
Je te suggère de jeter un coup d'oeil sur cette discussion qui aborde l'histoire du bonhomme NULL et qui dispatche les attributs, non pas en termes d'information renseignée, mais en termes de clés étrangères : c'est là le "vrai débat", me semble-t-il.
Partager