Sqlserver
 sql >> Base de Dados >  >> RDS >> Sqlserver

Chave primária composta versus coluna de ID adicional?


Diga que {Author, Title, Edition} identifica exclusivamente um livro, então o seguinte é válido:

  1. É uma superchave -- identifica exclusivamente uma tupla (linha).

  2. É irredutível - remover qualquer uma das colunas não a torna mais uma chave.

  3. É uma chave candidata -- uma superchave irredutível é uma chave candidata.

Agora vamos considerar o ID (inteiro)

Posso raciocinar que o Book table key aparecerá em poucas outras tabelas como uma chave estrangeira e também em alguns índices. Então, vai demorar um pouco de espaço -- digamos três colunas x 40 caracteres (ou o que for...) -- em cada uma dessas tabelas mais nos índices correspondentes.

Para tornar essas "outras" tabelas e índices menores, posso adicionar uma coluna de inteiro exclusivo ao Book tabela a ser usada como uma chave que será referenciada como uma chave estrangeira. Diga algo como:
alter table Book add BookID integer not null identity;

Com BookID sendo (deve ser) único também, o Book table agora tem duas chaves candidatas.

Agora posso selecionar o BookID como chave primária.
alter table Book add constraint pk_Book primary key (BookID);

No entanto, o {Author,Title,Edition} deve manter uma chave (única) para evitar algo assim:
BookID  Author      Title           Edition
-----------------------------------------------
  1      C.J.Date  Database Design     1
  2      C.J.Date  Database Design     1

Para resumir, adicionando o BookID -- e escolhê-lo como principal -- não interrompeu {Author, Title, Edition} sendo uma chave (candidata). Ele ainda deve ter sua própria restrição exclusiva e geralmente o índice correspondente.

Observe também que, do ponto de vista do design, essa decisão foi feita no "nível físico". Em geral, no nível lógico do design, este ID não existe -- ele foi introduzido durante a consideração dos tamanhos e índices das colunas. Assim, o esquema físico foi derivado do lógico. Dependendo do tamanho do banco de dados, RDBMS e hardware usado, nenhum raciocínio de tamanho pode ter efeito mensurável -- então, usar {Author, Title, Edition} como um PK pode ser um design perfeitamente bom - até que se prove o contrário.