Dans les relations maître-détail, les tables de détail contiennent-elles des colonnes d'ID?Est-ce que la table Détails contient une colonne ID dans la relation maître-détail?
Ou devrait-il?
Dans la base de données Northwind, OrderDetail n'a pas de colonne d'ID.
Toute table de données contenant un élément que vous voulez récupérer doit toujours contenir une clé primaire - c'est son travail principal: identifier de façon unique une seule ligne. Le simple fait que les détails appartiennent à une ligne maîtresse ne signifie pas qu'ils ne sont pas des lignes de données complètes elles-mêmes - elles doivent être identifiables d'une manière ou d'une autre. Donc oui - Je recommanderais n'importe quelle table de détail d'avoir une forme de clé primaire ("ID"). Il est possible de décider au cas par cas si cette connexion est ou non liée à l'ID principal, mais il doit y avoir un moyen d'identifier chaque rangée de détails de façon indépendante.
Si vous disposez d'une table de liens pour une relation M: N, vous ne disposez généralement que des deux colonnes de clé étrangère (pour les tables 1 et 2). C'est généralement assez bon, car la combinaison de ces deux FK est unique. La seule raison d'ajouter un ID distinct à une telle table serait si vous avez besoin d'ajouter des informations supplémentaires qui décrivent la relation en soi.
Mais même dans ce cas, tant que la combinaison (key1, key2) est unique, c'est généralement assez bon.
Dans la base de données Northwind, OrderDetail n'a pas de colonne ID. Et quel est votre commentaire sur la présence d'une colonne ID dans la table Join-table d'une relation M-à-M? – anonymous
Oui, Northwind. [Détails de la commande] utilise la combinaison de (OrderID, ProductID) comme PK. Cela fonctionne bien tant que vous n'aurez jamais deux lignes de commande faisant référence au même produit. Je ne pense pas que cette configuration soit très intelligente - personnellement j'utiliserais un OrderDetailsID séparé dans ce cas. –