clé comme une clé Surrogate étrangère sur les clés composites

Question

je me rends compte qu'il pourrait y avoir des questions similaires, mais je ne pouvais pas trouver un qui était assez proche pour obtenir des conseils.

Compte tenu de 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 œuvre 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 
... 

ya un problème avec cela? Est-ce normal que le substitut SeriesID soit une clé étrangère? Je ne suis pas sûr si je suis absent des problèmes évidents qui peuvent survenir. Ou serait-il préférable d'utiliser des clés naturelles composites (SiteID + SeriesCode/SiteID + EpisodeCode)? En substance, cela découplerait la table des épisodes de la table des séries et cela ne me convient pas. Il convient d'ajouter que SeriesCode ressemble à 'ABCD-1' et EpisodeCode comme 'ABCD-1NMO9' dans les données d'entrée brutes qui vont peupler ces tables, donc c'est une autre chose qui pourrait être modifiée je suppose.

*: « virtuelle » clé étrangère, car il a été précédemment décidé par les plus-ups nous ne devrions pas utiliser réelles clés étrangères

Answer 1

Oui, tout semble bien. Le seul point (mineur) que je pourrais faire est que, sauf si vous avez une autre table 4ème enfant suspendue d'Episode, vous n'avez probablement pas besoin EpisodeId, comme Episode.EpisodeCode est une clé naturelle unique attribut suffisant pour identifier et localiser les lignes dans Episode. Il n'y a pas de mal à le laisser là, bien sûr, mais en règle générale, j'ajouter des clés de substitution pour agir en tant que cibles pour FKs dans les tables enfant et essayez d'ajouter une touche narural à 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 référençant, (et ne le sera jamais), je n'embête parfois pas d'y inclure une clé de substitution.

Answer 2

Qu'est-ce qu'une clé étrangère « virtuelle »? Les plus hauts ont-ils décidé de ne pas utiliser les contraintes de clés étrangères? Dans ce cas, vous n'utilisez aucune clé étrangère. Vous faites juste semblant de.

Et est l'épisode le meilleur choix pour une entité? Cela ne signifie-t-il pas vraiment Show ou Podcast ou alors, et arrive-t-il toujours de faire partie d'une série en ce moment? Si oui, cela changera-t-il dans le futur? Est-ce que Episode sera finalement abusé pour englober Show en dehors d'une série? Dans ce cas, attacher Episode au site via la série pourrait revenir vous hanter.

Compte tenu de tout cela, et en supposant que vous grognant probablement ne peut pas changer tout ça: si je vous je me sentirais plus en sécurité en utilisant les touches naturelles chaque fois que possible. En l'absence de contraintes de clés étrangères, il est plus facile de reconnaître les mauvaises données, et si vous devez recourir ultérieurement à une supercherie de type "SERVEUR", c'est plus facile avec les clés naturelles.

Answer 3

Ma suggestion:

utilisation naturelle/entreprise comme clé primaire lorsque cela est possible, sauf dans les 3 situations suivantes:

1. La clé naturelle/d'affaires est inconnue au moment de l'insertion
2. La clé naturelle/commerciale est pas bon (ce n'est pas unique, il est susceptible de changer fréquemment)
3. La clé naturelle/entreprise est un composite de plus de 3 colonnes et la table aura des tables enfant

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

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