Aucun risque. C'est juste que généralement, c'est pour éviter d'avoir une unique table avec des champs souvent vides. Ca améliore la logique de stockage, mais pas celle d'interrogation, et les requêtes sont allourdies inutilement. Mais ce n'est pas gênant en soit.
Par exemple, imaginons que t'as une table "client", et tu sais qu'un client peu parfois avoir une et une seule voiture, mais pas toujours. A ce moment, soit tu crées une seconde table "voiture", avec ce type de clé, soit tu crées des champs nullable dans "client" pour stocker les infos de "voiture". Tout mettre dans une seule table sera bien plus simple pour écrire des requêtes du style "je veux tous les clients qui n'ont pas de voiture : "select * from client where voiture is null", alors que si t'as deux tables, tu pars tout de suite dans une requête bien plus complexe (et inifiment plus lente). Mais bon, ce n'est pas bloquant, dans certains cas, ça peut tout à fait être justifié.
weblook$$ a écrit :
si la clef étrangère référence une clef primaire, ça assure également l'unicité des données dans la table possédant la clef étrangère , non ?
|
Pas du tout. Rien ne t'empêche de tenter d'insérer un doublon dans la table fille. C'est le fait que la clé étrangère soit aussi une clé primaire qui garantie que tu n'auras jamais de doublons.