chave substituta como uma chave estrangeira sobre chaves compostas

Question

Eu percebo que pode haver questões semelhantes, mas eu não poderia encontrar um que estava perto o suficiente para orientação.

Dada esta especificação,

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)
...

minha proposta de concepção / implementação é

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
...

errado Qualquer coisa com isso? É bom ter o substituto SeriesID como uma chave * estrangeiro aqui? Eu não tenho certeza se eu estou faltando quaisquer problemas óbvios que podem surgir. Ou seria melhor usar chaves naturais compostas (SiteID + SeriesCode / SiteID + EpisodeCode)? No essencial, que iria separar a tabela Episódio da tabela da série e que não se sente certo para mim.

Vale acrescentar é que parece SeriesCode como 'ABCD-1' e EpisodeCode como 'ABCD-1NMO9' nos dados de entrada brutos que povoam essas tabelas, de modo que é outra coisa que poderia ser mudado suponho.

*: chave estrangeira "virtual", uma vez que foi decidido anteriormente por os superiores não devemos usar chaves estrangeiras reais

Answer 1

Sim, tudo parece bem. A única (menor) ponto que eu poderia fazer é que a menos que tenha outra tabela 4ª criança pendurada fora do episódio, você provavelmente não precisa EpisodeId, como Episode.EpisodeCode é uma chave natural único atributo suficiente para identificar e localizar as linhas no episódio. Não é nenhum dano a deixá-lo lá, é claro, mas como regra geral, eu adicionar chaves substitutas para agir como alvos para FKs em tabelas filho, e tentar adicionar uma chave Narural para cada mesa para linhas de dados redundantes identificar e controle ... Então, se uma tabela não tem outra mesa com uma FK referência a ele, (e nunca será) eu às vezes não se preocupam incluindo uma chave substituta na mesma.

Answer 2

O que é uma chave estrangeira "virtual"? Será que os superiores decidir não usar chaves estrangeiras? Nesse caso, você não está usando chaves estrangeiras em tudo. Você está apenas fingindo.

E é Episode a melhor escolha para uma entidade? Não que isso realmente significa Mostrar ou Podcast ou assim, e só acontece de ser sempre parte de uma série agora? Se assim for, será que a mudança no futuro? Vai Episode eventualmente, ser abusado para abranger Mostrar fora de uma série? Nesse caso, amarrando Episode ao site via Series pode voltar para assombrá-lo.

Diante de tudo isso, e supondo que você, como um grunhido provavelmente não pode mudar nada disso: se eu fosse você eu me sentiria mais seguro usando chaves naturais sempre que possível. Na ausência de restrições de chave estrangeira, faz o reconhecimento mais fácil de dados ruins, e se você tem que recorrer a alguns SeriesCode = 'vazio' malandragem, mais tarde, que é mais fácil com chaves naturais, também.

Answer 3

A minha sugestão:

Use natural / negócio como chave primária, sempre que possível , excepto nas 3 situações seguintes:

1. A chave natural / negócio é desconhecido no momento da inserção
2. A chave / negócios natural é não é bom (não é único, é susceptível de mudar frequentemente)
3. A chave natural / negócio é um composto de mais de 3 colunas e a mesa terá tabelas filho

Em situações 1 e 2 uma chave substituta é requiered .

Na situação 3 uma chave substituta é fortemente recomendado .