Remplacez la clé en tant que clé étrangère sur des clés composites

Question

Je me rends compte qu'il pourrait y avoir des questions similaires, mais je ne pourrais pas en trouver une qui soit suffisamment proche pour vous guider.

Étant donné cette spécification,

Site
---------------------------
SiteID      int    identity
Name        varchar(50)

Series
---------------------
SiteID      int
SeriesCode  varchar(6)
...
--SeriesCode will be unique for every unique SiteID

Episode
----------------------
SiteID      int
SeriesCode  varchar(6)
EpisodeCode varchar(10)
...

ma conception / mise en oeuvre proposée est

Site
----------------------------
SiteID      int     identity
Name        varchar(50)


Series
-------------------------------------------
SeriesID    int     identity, surrogate key
SiteID      int         natural key
SeriesCode  varchar(6)  natural key
UNIQUE(SiteID, SeriesCode)
...

Episode
-------------------------------------------
EpisodeID   int     identity, surrogate key
SeriesID    int     foreign key
EpisodeCode varchar(6)  natural key
...

Quelque chose ne va pas avec ça? Est-il acceptable d'avoir le substitut SeriesID en tant que clé étrangère * ici? Je ne suis pas sûr si je manque des problèmes évidents qui peuvent survenir. Ou serait-il préférable d'utiliser des clés naturelles composites (SiteID + SeriesCode / SiteID + EpisodeCode)? Essentiellement, cela découplerait la table des épisodes de la table des séries et cela ne me conviendrait pas.

Il est intéressant de noter que SeriesCode ressemble à "ABCD-1" et à EpisodeCode à "ABCD-1NMO9" dans les données d'entrée brutes qui peupleront ces tableaux, c'est donc une autre chose qui pourrait être modifiée, je suppose.

*: " virtual " clé étrangère, comme il a été décidé précédemment par les supérieurs, nous ne devrions pas utiliser les réelles clés étrangères

Answer 1

Oui, tout va bien. Le seul point (mineur) que je pourrais dire est que, à moins que vous ayez une autre 4ème table enfant suspendue à Episode, vous n'avez probablement pas besoin d'EpisodeId, car Episode.EpisodeCode est une clé naturelle à attribut unique suffisante pour identifier et localiser les lignes dans Episode. Bien sûr, il n’ya pas de mal à en rester là, mais en règle générale, j’ajoute des clés de substitution servant de cibles pour les FK dans les tables enfants et essaie d’ajouter une clé naturelle à chaque table pour identifier et contrôler les lignes de données redondantes ... Donc, si une table n'a pas d'autre table avec un FK la référençant (et ne le fera jamais), parfois je ne dérange pas d'inclure une clé de substitution dans celle-ci.

Answer 2

Qu'est-ce qu'un "virtuel"? clé étrangère? Les supérieurs ont-ils décidé de ne pas utiliser les contraintes de clé étrangère? Dans ce cas, vous n'utilisez pas de clé étrangère. Vous ne faites que prétendre.

Et Episode est-il le meilleur choix pour une entité? Cela ne signifie-t-il pas vraiment Show ou Podcast, et il se trouve que cela fait toujours partie d'une série en ce moment? Si oui, cela changera-t-il à l'avenir? Episode sera-t-il éventuellement abusé pour inclure Show en dehors d'une série? Dans ce cas, lier Episode au site via une série peut revenir vous hanter.

Etant donné tout cela, et en supposant que vous ne pouvez probablement rien y changer: si j'étais vous, je me sentirais plus en sécurité en utilisant des clés naturelles dans la mesure du possible. En l'absence de contraintes de clé étrangère, la reconnaissance des données erronées est facilitée. Si vous devez recourir ultérieurement à une astuce SeriesCode = 'EMPTY', c'est plus facile avec les clés naturelles.

Answer 3

Ma suggestion:

Utilisez naturel / business comme clé primaire chaque fois que possible , sauf dans les 3 situations suivantes:

1. La clé naturelle / professionnelle est inconnue au moment de l'insertion
.
2. La clé naturelle / professionnelle n'est pas bonne (elle n'est pas unique, elle est susceptible de changer fréquemment)
3. La clé naturelle / professionnelle est composée de plus de 3 colonnes et la table aura des tables enfants
.

Dans les situations 1 et 2, une clé de substitution est obligatoire .

Dans la situation 3, une clé de substitution est fortement recommandée .