TL;DR Vous n'avez pas besoin pour déclarer une "relation", c'est-à-dire une clé étrangère (FK) à interroger. Mais c'est une bonne idée . Lorsque vous le faites, un FK peut référencer une clé primaire (PK) ou toute autre colonne UNIQUE.
Les PK et les FK sont appelés à tort "relations" dans certaines méthodes et produits. Les relations d'application sont représentées par des tableaux . (Tables de base et résultats de requête.) Les PK et les FK sont des contraintes :elles indiquent au SGBD que seules certaines situations peuvent survenir, afin qu'il puisse remarquer lorsque vous faites certaines erreurs. Ce ne sont pas des relations, ce sont des déclarations vraies dans &de chaque état de base de données et situation d'application. Vous n'avez pas besoin de connaître les contraintes pour mettre à jour et interroger une base de données.
Sachez juste ce que chaque table signifie . Les tables de base ont des significations données par DBA qui vous indiquent la signification de leurs lignes. Les requêtes ont également des significations qui vous indiquent la signification de leurs lignes. Les significations des requêtes sont combinées à partir des significations de la table de base parallèlement à la façon dont leurs valeurs de résultat sont combinées à partir des valeurs et des conditions de la table de base.
image_tbl-- l'image [Id] est dans un album nommé [albumName], est nommé [name], est daté du [dateTime] et a un commentaire [comment]album_tbl-- l'album [albumID] s'appelle [albumName]
Vous n'avez pas pour déclarer des PK/UNIQUES ou des FK ! Mais c'est une bonne idée car alors le SGBD peut interdire les mises à jour impossibles/erronées. Un PK/UNIQUE indique qu'une valeur de sous-ligne pour ses colonnes ne doit apparaître qu'une seule fois. Un FK indique qu'une valeur de sous-ligne pour ses colonnes doit apparaître comme une valeur de sous-ligne PK/UNIQUE dans sa table référencée. Le fait que ces limitations s'appliquent aux tables de base signifie que certaines limitations s'appliquent aux résultats de la requête. Mais la signification de ces résultats de requête dépend des combinaisons de table et de condition de la requête, indépendamment de ces limitations. Par exemple, si les noms d'albums sont uniques ou non,
image_tbl JOIN album_tbl USING albumName-- l'image [Id] est dans un album nommé [albumName], est nommé [name], est daté du [dateTime] et a un commentaire [comment] ET l'album [albumID] est nommé [albumName]
Le seul problème ici est que si les noms d'album ne sont pas uniques, connaître le nom de l'album d'une image ne vous dira pas dans quel album il se trouve ; vous savez seulement que c'est dans un album avec ce nom. D'autre part, si les noms d'album sont uniques, vous n'avez pas besoin de album_tbl albumID.
Donc, si les noms d'album sont uniques, déclarez albumName UNIQUE dans album_tbl. Ensuite dans image_tbl identifiez l'album par une colonne PK/UNIQUE de album_tbl. Étant donné que album_id est vraisemblablement présent uniquement dans le but d'identifier les albums, nous nous attendrions normalement à ce qu'il soit choisi. Ensuite, dans image_tbl, déclarez cette colonne en tant que FK faisant référence à album_tbl.
Les index PS accélèrent généralement les requêtes au prix d'un certain temps et d'espace. Une déclaration de clé primaire dans une déclaration de table déclare automatiquement un index. C'est une bonne idée d'indexer les ensembles de colonnes PK, UNIQUE et FK.
