Substituto vs. chaves naturais / comerciais [fechado]


173

Aqui vamos nós de novo, o velho argumento ainda surge ...

Seria melhor termos uma chave comercial como chave primária ou preferiríamos um ID substituto (ou seja, uma identidade do SQL Server) com uma restrição exclusiva no campo chave comercial?

Por favor, forneça exemplos ou provas para apoiar sua teoria.


24
@Joachim Sauer: Um argumento sobre se uma coisa é subjetiva pode ser subjetivo, sem que isso tenha relação com a objetividade ou a subjetividade da coisa em questão. A menos que você esteja preparado para indicar os critérios objetivos exatos que tornam algo objetivo. Existem coisas chamadas "conceitos abertos", como quantos cabelos são necessários para fazer uma barba. Pode-se dizer objetivamente que uma pessoa sem pêlos no queixo não tem barba e uma com 5.000 pêlos de uma polegada de comprimento tem barba, mas em algum lugar no meio do julgamento subjetivo é necessário fazer uma determinação objetiva.
ErikE 02/02/10

@Manrico: você só precisa se perguntar o seguinte: se eu não usar uma chave substituta, minha chave primária ainda será imutável? Se a resposta for não, considere seriamente usar uma chave substituta. Além disso, se a chave primária for composta mesmo parcialmente pelas entradas do usuário, considere usar uma chave substituta. Por quê? Por causa do perigo de anomalias de dados.
code4life

@TylerRick Mas essa não é uma pergunta perfeitamente boa. Ele pede uma solução que seja geralmente aplicável a todas as situações, quando claramente não há uma, como comprovado pela "guerra religiosa" da qual o solicitante está perfeitamente ciente (citação: "Aqui vamos nós novamente, o velho argumento ainda surge. .. "). Em vez de se perguntar se o mundo mudou e, finalmente, foi fornecido um motivo convincente para escolher um lado o tempo todo, é melhor continuar repetindo essa pergunta para cada situação concreta e postar no SO quando não tiver certeza . Isso apenas provoca dogmatismo.
MarioDS 19/08/16

Respostas:


96

Ambos. Tome seu bolo e coma.

Lembre-se de que não há nada de especial em uma chave primária, exceto que ela é rotulada como tal. Não é nada além de uma restrição NOT NULL UNIQUE, e uma tabela pode ter mais de uma.

Se você usar uma chave substituta, ainda desejará uma chave comercial para garantir exclusividade de acordo com as regras comerciais.


7
Se você tiver várias chaves "candidatas" (campos ou coleções do mesmo tamanho de campos que NÃO SÃO NULOS ÚNICOS), é provável que você esteja violando o Formulário Normal Boyce-Codd. O BCNF está além do 3NF, então muitas pessoas não se preocupam com isso. No entanto, existem situações em que estar no BCNF é muito útil.
Alan Alan

2
Acordado. A verdadeira questão deve ser: devo adicionar uma chave substituta exclusiva às minhas tabelas? Uma outra questão é o que usar para uma chave primária lógica. Ambos são essencialmente apenas restrições de índice exclusivas não nulas.
22410 dkretz

1
"Todo problema é resolvido com outro nível de engano" ... As chaves substitutas são apenas isso: um outro nível de engano
Steve Schnepp

5
Acho estranho que muitos comentários pareçam afirmar que não se pode estabelecer um relacionamento sem uma chave substituta. Em muitos casos, a chave substituta é supérflua. Por que adicionar algo que não agrega valor, mas agrega dívida técnica (e, em alguns casos, faz com que um resultado único se torne repentinamente não exclusivo).
Wil Moore III

2
É mais do que uma restrição NÃO NULL UNIQUE. A chave primária é usada como um índice clusterizado que determina a ordem física dos seus dados. Em geral, o número inteiro é fácil de equilibrar, pois aumenta sequencialmente e seus dados serão anexados ao EOF no disco. Se você usar menos dados sequenciais como texto ou GUID (UUID), haverá muito mais IO de disco e esforço para equilibrar o índice, eu acho que é tipo de grande diferença
Jin

124

Apenas algumas razões para usar chaves substitutas:

  1. Estabilidade : alterar uma chave devido a uma necessidade comercial ou natural afetará negativamente as tabelas relacionadas. As chaves substitutas raramente, se alguma vez, precisam ser alteradas porque não há significado vinculado ao valor.

  2. Convenção : Permite que você tenha uma convenção de nomenclatura padronizada da coluna Chave Primária, em vez de precisar pensar em como associar tabelas com vários nomes para suas PKs.

  3. Velocidade : Dependendo do valor e tipo de PK, uma chave substituta de um número inteiro pode ser menor, mais rápida para indexar e pesquisar.


2
Agora, depois de ler muito sobre chaves substitutas e chaves naturais, acho que usar chaves substitutas é melhor. Mas, no meu banco de dados, as chaves naturais (um NVARCHAR (20)) devem ser únicas. Eu não entendo como posso obter mais velocidade se precisar verificar todos os dados dessa coluna para não repetir nenhum valor (usando uma restrição NOT NULL UNIQUE UNIQUE) em cada inserção.
VansFannel

70

Parece que ninguém ainda disse algo em apoio a chaves não substitutas (hesito em dizer "naturais"). Então aqui vai ...

Uma desvantagem das chaves substitutas é que elas não têm sentido (citadas como uma vantagem por alguns, mas ...). Às vezes, isso obriga a associar muito mais tabelas à sua consulta do que realmente seria necessário. Comparar:

select sum(t.hours)
from timesheets t
where t.dept_code = 'HR'
and t.status = 'VALID'
and t.project_code = 'MYPROJECT'
and t.task = 'BUILD';

contra:

select sum(t.hours)
from timesheets t
     join departents d on d.dept_id = t.dept_id
     join timesheet_statuses s on s.status_id = t.status_id
     join projects p on p.project_id = t.project_id
     join tasks k on k.task_id = t.task_id
where d.dept_code = 'HR'
and s.status = 'VALID'
and p.project_code = 'MYPROJECT'
and k.task_code = 'BUILD';

A menos que alguém pense seriamente o seguinte é uma boa ideia ?:

select sum(t.hours)
from timesheets t
where t.dept_id = 34394
and t.status_id = 89    
and t.project_id = 1253
and t.task_id = 77;

"Mas" alguém dirá "o que acontece quando o código para MYPROJECT, VALID ou HR muda?" Para qual minha resposta seria: "por que você precisaria mudar isso?" Essas não são chaves "naturais" no sentido de que algum órgão externo vai legislar que, a partir de agora, "VÁLIDO" deve ser recodificado como "BOM". Apenas uma pequena porcentagem de chaves "naturais" realmente se enquadra nessa categoria - SSN e CEP são os exemplos usuais. Eu definitivamente usaria uma tecla numérica sem sentido para tabelas como Pessoa, Endereço - mas não para tudo , o que, por algum motivo, a maioria das pessoas aqui parece defender.

Veja também: minha resposta para outra pergunta


14
-1 As chaves naturais como chave primária têm o problema de que, para cada tabela filho, você deve adicionar a chave do pai, que pode ser composta por mais de um campo (em vez de apenas um que é o caso de uma chave substituta) e também o filho chave. Imagine o seguinte, onde, a partir de TABLEA, o relacionamento é 1-0 .. *: TABLEA PK: ID_A TABLEB PK: ID_A ID_B TABLEC PK: ID_A ID_B ID_B ID_C TABELA PK: ID_A ID_B ID_C ID_D. Vê o problema? A chave pai é propagada nas tabelas filhas. O que aconteceria se a chave primária do TABLEA fosse alterada? Agora você também teria que refatorar todas as tabelas filho PK.
Alfredo Osorio

9
@ Alfredo: sim, é claro que há um trade-off. No entanto, nos meus mais de 20 anos de experiência, raramente vi a definição de alteração de PK de uma tabela. Se isso acontecesse regularmente, eu provavelmente evitaria chaves naturais também. Na realidade, nas raras ocasiões em que isso acontece, estou preparado para sofrer o impacto prolongado.
18711 Tony Tonys

10
Discordo. Geralmente, é o caso em que algum órgão externo (o cliente) legisla que uma chave natural precisa ser editada e, portanto, propagada por todo o sistema. Eu vejo isso acontecer regularmente. A única maneira de ter certeza de que a chave nunca precisará mudar é quando ela é, por definição, sem sentido. Além disso, os bancos de dados modernos lidam com junções internas de maneira extremamente eficiente, portanto os ganhos de espaço potencialmente grandes com o uso de substitutos geralmente superam a vantagem de não ter que fazer tantas junções internas.
TTT

8
@TTT: Então o design era fraco para começar. Novamente, é aí que os homens se separam dos meninos: fazendo a escolha certa de quando usar a chave natural e quando usar um substituto. Você decide isso por tabela, não como um dogma geral.
DanMan

7
Eu também tenho mais de 20 anos de experiência e apóio sua opinião. Certa vez, criei um datawarehouse da Oracle com chaves substitutas e a manutenção de dados foi como o inferno. Você simplesmente nunca pode acessar diretamente seus dados. você sempre precisa escrever consultas para tudo, e isso torna as chaves substitutas simplesmente horríveis de lidar.
SQL Police

31

A chave substituta NUNCA terá um motivo para mudar. Não posso dizer o mesmo sobre as chaves naturais. Sobrenomes, e-mails, numeradores de ISBN - todos eles podem mudar um dia.


31

As chaves substitutas (normalmente números inteiros) têm o valor agregado de tornar as relações da tabela mais rápidas e mais econômicas na velocidade de armazenamento e atualização (ainda melhor, chaves estrangeiras não precisam ser atualizadas ao usar chaves substitutas, em contraste com os campos das chaves comerciais, que mudam de vez em quando).

A chave primária de uma tabela deve ser usada para identificar exclusivamente a linha, principalmente para fins de junção. Tabela Pense em uma pessoa: os nomes podem mudar e não têm garantia de exclusividade.

Think Companies: você é uma empresa feliz da Merkin que faz negócios com outras empresas da Merkia. Você é esperto o suficiente para não usar o nome da empresa como chave primária; portanto, você usa o ID exclusivo da empresa do governo da Merkia em seus 10 caracteres alfanuméricos. Então a Merkia altera os IDs da empresa porque eles acharam que seria uma boa ideia. Tudo bem, você usa o recurso de atualizações em cascata do seu mecanismo de banco de dados, para uma alteração que não deve envolver você em primeiro lugar. Mais tarde, seus negócios se expandem e agora você trabalha com uma empresa na Freedonia. O ID da empresa freedoniana tem até 16 caracteres. Você precisa aumentar a chave primária de identificação da empresa (também os campos de chave estrangeira em Pedidos, Emissões, MoneyTransfers etc.), adicionando um campo País na chave primária (também nas chaves estrangeiras). Ai! Guerra civil na Freedonia, é s divididos em três países. O nome do país do seu associado deve ser alterado para o novo; atualizações em cascata para o resgate. BTW, qual é a sua chave primária? (Country, CompanyID) ou (CompanyID, Country)? O último ajuda a participar, o primeiro evita outro índice (ou talvez muitos, caso você deseje que seus pedidos sejam agrupados por país também).

Tudo isso não é prova, mas uma indicação de que uma chave substituta para identificar exclusivamente uma linha para todos os usos, incluindo operações de junção, é preferível a uma chave comercial.


Você ganha todas as internets com o nome de usuário mais legal!
Iain Holder

1
Isso é basicamente o que é um voto negativo: "Eu não concordo com isso".
jcollum

5
A dica de ferramenta da seta para baixo diz "Esta resposta não é útil", não "Não concordo com isso". Talvez nesta resposta específica os significados estejam próximos, mas geralmente não são os mesmos.
tzot

1
Se alguém achar que sua resposta está errada, ele também achará que leva o interlocutor na direção errada (oposta à direção correta) e, portanto, julgará sua resposta ainda pior do que "inútil", justificando em sua mente um voto negativo.
precisa saber é o seguinte

1
Sim, chaves substitutas são uma doença. Um vaza para a natureza e você o usa como um pkey; agora, você precisa de sua própria chave substituta. Então sua chave vaza para a natureza (digamos, por meio de um URL) e a doença se espalha.
Samuel Danielson

25

Eu odeio chaves substitutas em geral. Eles devem ser usados ​​apenas quando não houver chave natural de qualidade disponível. É bastante absurdo, quando você pensa sobre isso, pensar que adicionar dados sem sentido à sua tabela poderia melhorar as coisas.

Aqui estão as minhas razões:

  1. Ao usar chaves naturais, as tabelas são agrupadas da maneira que são pesquisadas com mais frequência, agilizando as consultas.

  2. Ao usar chaves substitutas, você deve adicionar índices exclusivos nas colunas de chaves lógicas. Você ainda precisa impedir dados duplicados lógicos. Por exemplo, você não pode permitir duas organizações com o mesmo nome na tabela Organização, mesmo que o pk seja uma coluna de identificação substituta.

  3. Quando as chaves substitutas são usadas como chave primária, fica muito menos claro o que são as chaves primárias naturais. Ao desenvolver, você deseja saber qual conjunto de colunas torna a tabela exclusiva.

  4. Em uma a muitas cadeias de relacionamento, as cadeias de chaves lógicas. Por exemplo, as organizações têm muitas contas e as contas têm muitas faturas. Portanto, a chave lógica da organização é OrgName. A chave lógica de contas é OrgName, AccountID. A chave lógica da fatura é OrgName, AccountID, InvoiceNumber.

    Quando chaves substitutas são usadas, as cadeias de chaves são truncadas por ter apenas uma chave estrangeira para o pai imediato. Por exemplo, a tabela Fatura não possui uma coluna OrgName. Ele possui apenas uma coluna para o AccountID. Se você deseja pesquisar faturas para uma determinada organização, precisará ingressar nas tabelas Organização, Conta e Fatura. Se você usar chaves lógicas, poderá consultar a tabela Organização diretamente.

  5. Armazenar valores-chave substitutos de tabelas de pesquisa faz com que as tabelas sejam preenchidas com números inteiros sem sentido. Para visualizar os dados, devem ser criadas visualizações complexas que se juntam a todas as tabelas de pesquisa. Uma tabela de pesquisa deve conter um conjunto de valores aceitáveis ​​para uma coluna. Não deve ser codificado armazenando uma chave substituta inteira. Não há nada nas regras de normalização que sugira que você armazene um número inteiro substituto em vez do próprio valor.

  6. Eu tenho três livros diferentes de banco de dados. Nenhum deles mostra usando chaves substitutas.


7
Eu odeio chaves substitutas, exceto quando são necessárias. Eles são necessários quando a empresa usa uma chave natural sujeita a muitos erros e não estão dispostos a tolerar um banco de dados impactado por esses erros.
Walter Mitty

26
-1: Eu escrevi e mantive dezenas de aplicativos. Os que apresentaram mais problemas relacionados aos dados foram os que usaram chaves naturais.
Falcon

6
Alguns de seus pontos assumem que a chave substituta deve ser a PK ou a coluna em cluster - não é verdade. Seus pontos 1 e 5 ignoram o fato de que números inteiros são 4 bytes e chaves naturais são quase sempre muitos, muitos mais bytes. E cada índice não clusterizado deve repetir os bytes dessas chaves naturais que estão no índice clusterizado, para que as tabelas e índices no banco de dados de chaves naturais tenham muito, muito menos linhas por página, o que resulta em um desempenho de leitura muito pior , o que torna as consultas mais lentas , não mais rápidas.
ErikE

3
Outro motivo para as chaves naturais (exemplos: números atômicos, VINs etc.), a lógica de negócios pode mudar, aumentando o tipo de dados. Por exemplo - Antes: Rastrear cobranças de átomos, Depois: Rastrear cobranças de átomos e compostos. Antes: Rastreamento de veículos a motor quanto à capacidade de carga. Depois: Adicionando aviões, barcos, bicicletas e pessoas para capacidade de carga.
forforf

3
Eu acho que você não tem tabelas onde a chave primária é composta, mesmo parcialmente, de 1) qualquer atributo que possa e irá mudar) ou 2) da entrada do usuário (por exemplo, listas de pesquisa geradas dinamicamente). Se você não pode garantir a imutabilidade da chave, precisará atualizar todos esses relacionamentos de entidade por código ou por scripts de "correção" manual. Se você nunca fez isso ... acho que seu banco de dados é substituto sem chave e ... incomum.
code4life

18

Quero compartilhar minha experiência com você nesta guerra sem fim: D sobre o dilema natural versus substituto. Penso que tanto as chaves substitutas (as artificiais geradas automaticamente) como as naturais (compostas por colunas com significado de domínio) têm prós e contras . Portanto, dependendo da sua situação, pode ser mais relevante escolher um método ou outro.

Como parece que muitas pessoas apresentam chaves substitutas como a solução quase perfeita e chaves naturais como praga, vou me concentrar nos argumentos do outro ponto de vista:

Desvantagens de chaves substitutas

As chaves substitutas são:

  1. Origem dos problemas de desempenho:
    • Eles geralmente são implementados usando colunas com incremento automático, o que significa:
      • Uma viagem de ida e volta ao banco de dados toda vez que você deseja obter um novo ID (eu sei que isso pode ser aprimorado usando algoritmos de armazenamento em cache ou [seq] hilo, mas ainda assim esses métodos têm suas próprias desvantagens).
      • Se um dia você precisar mover seus dados de um esquema para outro (isso acontece com bastante frequência na minha empresa), você poderá encontrar problemas de colisão de ID. E sim, eu sei que você pode usar UUIDs, mas esses últimos requerem 32 dígitos hexadecimais! (Se você se preocupa com o tamanho do banco de dados, pode ser um problema).
      • Se você estiver usando uma sequência para todas as suas chaves substitutas, então - com certeza - você terminará com contenção no seu banco de dados.
  2. Propenso a erros. Uma sequência tem um limite de max_value, portanto, como desenvolvedor, você deve prestar atenção aos seguintes pontos:
    • Você deve alternar sua sequência (quando o valor máximo é atingido, ele volta para 1,2, ...).
    • Se você estiver usando a sequência como uma ordenação (ao longo do tempo) de seus dados, deverá lidar com o caso do ciclismo (a coluna com o ID 1 pode ser mais nova que a linha com o ID max-value - 1).
    • Verifique se o seu código (e até a interface do cliente, que não deve acontecer como deveria ser um ID interno) suporta números inteiros 32b / 64b que você usou para armazenar seus valores de sequência.
  3. Eles não garantem dados não duplicados. Você sempre pode ter 2 linhas com os mesmos valores de coluna, mas com um valor gerado diferente. Para mim, este é O problema das chaves substitutas de um ponto de design de banco de vista.
  4. Mais na Wikipedia ...

Mitos sobre chaves naturais

  1. Chaves compostas são menos ineficientes do que chaves substitutas. Não! Depende do mecanismo de banco de dados usado:
  2. Chaves naturais não existem na vida real. Desculpe, mas eles existem! No setor de aviação, por exemplo, a tupla a seguir será sempre única em relação a um determinado voo programado (companhia aérea, data de partida, número de vôo, número de vôo, número operacional). De maneira mais geral, quando um conjunto de dados comerciais é garantido como único por um determinado padrão , esse conjunto de dados é um [bom] candidato a chave natural.
  3. As chaves naturais "poluem o esquema" das tabelas filho. Para mim, isso é mais um sentimento do que um problema real. Ter uma chave primária de 4 colunas de 2 bytes cada pode ser mais eficiente do que uma única coluna de 11 bytes. Além disso, as 4 colunas podem ser usadas para consultar diretamente a tabela filho (usando as 4 colunas em uma cláusula where) sem ingressar na tabela pai.

Conclusão

Use chaves naturais quando for relevante e use chaves substitutas quando for melhor usá-las.

Espero que isso tenha ajudado alguém!


3
O que acontece quando a data de partida do voo programado é reagendada? Você precisa rastrear todas as entidades relacionadas e excluir as chaves ou atualiza todas as chaves nas entidades relacionadas? Ou você está lidando com uma tabela simples e singular (possivelmente nem 3NF)?
code4life

Ponto excelente @ code4life
forcewill

@ code4life: É aí que o operacionalSuffix entra em cena. Para manter o mesmo número de vôo, para evitar confusão do cliente, adicionamos apenas um sufixo (por exemplo, 'D').
Mknsiri

"Você sempre pode ter 2 linhas com os mesmos valores de coluna, mas com um valor gerado diferente", basta colocar uma restrição única ou composta única em suas colunas.
Wha7ever 13/09/19

15

Sempre use uma chave que não tenha significado comercial. É apenas uma boa prática.

EDIT: Eu estava tentando encontrar um link para ele online, mas não consegui. No entanto, em 'Patterns of Enterprise Archtecture' [Fowler], há uma boa explicação de por que você não deve usar outra coisa senão uma chave sem outro significado além de ser uma chave. Tudo se resume ao fato de que ele deve ter um emprego e apenas um emprego.


22
Martin Fowler pode ser muitas coisas, mas ele não é uma autoridade no design de banco de dados.
22310 Tony Tonys

Eu acho que você deve fornecer algum raciocínio antes de chegar à conclusão.
Arne Evertsson

4
@ArneEvertsoon O motivo está aí. "Tudo se resume ao fato de que ele deve ter um emprego e apenas um emprego." Responsabilidade única.
Iain Titular

10

Chaves substitutas são bastante úteis se você planeja usar uma ferramenta ORM para manipular / gerar suas classes de dados. Embora você possa usar chaves compostas com alguns dos mapeadores mais avançados (leia-se: hibernar), isso adiciona alguma complexidade ao seu código.

(Obviamente, os puristas de banco de dados argumentam que mesmo a noção de uma chave substituta é uma abominação.)

Sou fã de usar uids para chaves substitutas quando adequado. A principal vantagem deles é que você conhece a chave com antecedência, por exemplo, é possível criar uma instância de uma classe com o ID já definido e garantido que seja único, enquanto que, por exemplo, com uma chave inteira, você precisará usar como padrão 0 ou - 1 e atualize para um valor apropriado ao salvar / atualizar.

Os UIDs têm penalidades em termos de pesquisa e velocidade de junção, portanto, depende do aplicativo em questão se eles são desejáveis.


6

Usar uma chave substituta é melhor na minha opinião, pois não há chance de ela mudar. Quase qualquer coisa que eu possa pensar que você possa usar como chave natural pode mudar (aviso: nem sempre é verdade, mas geralmente).

Um exemplo pode ser um banco de dados de carros - à primeira vista, você pode pensar que a placa do carro possa ser usada como chave. Mas isso pode ser alterado para que seja uma má ideia. Você realmente não gostaria de descobrir isso depois de lançar o aplicativo, quando alguém o procura , querendo saber por que eles não podem mudar sua chapa de matrícula para a nova e personalizada e brilhante.


1
Infelizmente carros têm uma chave natural que não muda: o VIN (pelo menos na América ...)
jcollum

@ jcollum Sim, ok, esse é um ponto justo. Minha opinião ainda permanece, porém, meu exemplo não era necessariamente tão bom quanto poderia ser.
Mark Embling

2
Uma lista de idiomas seria um exemplo para uma chave natural, quando você a basear em códigos ISO. Portanto, se você deseja carregar o conteúdo de uma tabela em um determinado idioma, não precisará ingressar na languagestabela, pois o código do idioma (ID) já está na textstabela.
DanMan

@ Danman Eu tenho que concordar com você lá. Sempre haverá alguns exemplos que funcionam melhor com uma chave natural. Regras ou abordagens comuns não são absolutas, e que é um exemplo que eu gostaria 100% vão com a sua abordagem :-)
Mark Embling

5

Sempre use uma única coluna, chave substituta, se possível. Isso torna as junções e as inserções / atualizações / exclusões muito mais limpas, porque você é o único responsável por rastrear uma única informação para manter o registro.

Em seguida, conforme necessário, empilhe as chaves da sua empresa como restrições ou índices exclusivos. Isso manterá a integridade dos dados intacta.

Lógica comercial / chaves naturais podem mudar, mas a chave física de uma tabela NUNCA deve mudar.


4

Em um cenário de datawarehouse, acredito que é melhor seguir o caminho-chave substituto. Duas razões:

  • Você é independente do sistema de origem e as alterações nele, como uma alteração no tipo de dados, não o afetam.
  • Seu DW precisará de menos espaço físico, pois você usará apenas tipos de dados inteiros para suas chaves substitutas. Além disso, seus índices funcionarão melhor.

2

Chaves substitutas podem ser úteis quando as informações comerciais podem mudar ou ser idênticas. Afinal, os nomes comerciais não precisam ser exclusivos em todo o país. Suponha que você lide com duas empresas chamadas Smith Electronics, uma no Kansas e outra no Michigan. Você pode distingui-los por endereço, mas isso mudará. Até o estado pode mudar; e se a Smith Electronics de Kansas City, Kansas se mover através do rio para Kansas City, Missouri? Não há uma maneira óbvia de manter essas empresas distintas com informações de chave natural; portanto, uma chave substituta é muito útil.

Pense na chave substituta como um número de ISBN. Geralmente, você identifica um livro por título e autor. No entanto, tenho dois livros intitulados "Pearl Harbor", de HP Willmott, e são definitivamente livros diferentes, não apenas edições diferentes. Em um caso como esse, eu poderia me referir à aparência dos livros, ou mais cedo ou mais tarde, mas também é bom que eu tenha o ISBN para recorrer.


1
Eu acho que tenho que discordar do seu exemplo aqui. Um número de ISBN é um atributo de um livro. Uma chave substituta é independente do restante dos dados da linha; portanto, essa posição defenderia o uso de uma chave substituta separada para uma tabela de livros, mesmo que o ISBN já identifique exclusivamente todos os livros.
Christopher Cashell

Como alternativa, pense no ISBN como uma chave substituta em si. É um identificador sem significado, apenas um código aplicado a um livro específico. Se você estiver criando uma tabela de livros, o ISBN também pode ser a chave principal (supondo que você tenha e sempre tenha um livro por linha).
David Thornley 31/03

@ Christopher Cashell - Me deparei com este post de um ano atrás, mas pensei em adicionar algo. Não é garantido que os ISBNs sejam únicos e podem ter duplicatas. Eu tenho um amigo que trabalhou em uma biblioteca por vários anos e que geralmente se deparava com livros com ISBN duplicado. O problema é que a exclusividade do ISBN é de responsabilidade do editor, e não de um órgão que garante que todos os números de todas as publicações são únicos e esses editores nem sempre agem juntos.
Thomas

2
Me deparei com este post de um ano atrás e queria mencionar que o ISBN é de fato chaves naturais. Existe um significado inserido no próprio valor da chave, diferentemente de uma chave substituta. Por exemplo, parte da chave identifica o editor. Além disso, como mencionei acima, não é garantido que sejam únicos. Eles deveriam ser únicos, mas essa singularidade vem dos editores e nem sempre foram perfeitos.
Thomas

Tecnicamente, as empresas não podem se mover entre estados; o que acontece é que uma nova corporação é criada no novo estado e os ativos são transferidos. Isso funciona também para informações do banco de dados.
Warren Dew

2

Como lembrete, não é uma boa prática colocar índices agrupados em chaves substitutas aleatórias, isto é, GUIDs que lêem XY8D7-DFD8S, pois o SQL Server não pode classificar fisicamente esses dados. Em vez disso, você deve colocar índices exclusivos nesses dados, embora também seja vantajoso executar simplesmente o SQL Profiler para as operações da tabela principal e, em seguida, colocar esses dados no Orientador de Otimização do Mecanismo de Banco de Dados.

Consulte thread @ http://social.msdn.microsoft.com/Forums/en-us/sqlgetstarted/thread/27bd9c77-ec31-44f1-ab7f-bd2cb13129be


Tenho certeza de que o SQL Server pode classificar GUIDs.
Michael Green

Isso não é exato, embora eles possam avaliar o GUID, a classificação resultante não é absurda para um ser humano. stackoverflow.com/questions/7810602/…
Bryan Swan

1
Uma afirmação verdadeira, mas bem diferente de "O SQL Server não tem a capacidade de classificá-los fisicamente".
Michael Green

2

Caso 1: sua tabela é uma tabela de pesquisa com menos de 50 tipos (inserções)

Use chaves comerciais / naturais . Por exemplo:

Table: JOB with 50 inserts
CODE (primary key)       NAME               DESCRIPTION
PRG                      PROGRAMMER         A programmer is writing code
MNG                      MANAGER            A manager is doing whatever
CLN                      CLEANER            A cleaner cleans
...............
joined with
Table: PEOPLE with 100000 inserts

foreign key JOBCODE in table PEOPLE
looks at
primary key CODE in table JOB

Caso 2: sua mesa é uma tabela com milhares de inserções

Use chaves substitutas / incremento automático . Por exemplo:

Table: ASSIGNMENT with 1000000 inserts
joined with
Table: PEOPLE with 100000 inserts

foreign key PEOPLEID in table ASSIGNMENT
looks at
primary key ID in table PEOPLE (autoincrement)

No primeiro caso:

  • Você pode selecionar todos os programadores da tabela PEOPLE sem usar a junção com a tabela JOB, mas apenas com: "SELECT * FROM PEOPLE WHERE JOBCODE = 'PRG'"

No segundo caso:

  • Suas consultas ao banco de dados são mais rápidas porque sua chave primária é um número inteiro
  • Você não precisa se preocupar em encontrar a próxima chave exclusiva, porque o próprio banco de dados fornece o próximo incremento automático.

2

Este é um daqueles casos em que uma chave substituta quase sempre faz sentido. Há casos em que você escolhe o que é melhor para o banco de dados ou o que é melhor para o seu modelo de objeto, mas em ambos os casos, usar uma chave sem sentido ou GUID é uma idéia melhor. Torna a indexação mais fácil e rápida, e é uma identidade para o seu objeto que não muda.


1

Cavalo para cursos. Declarar meu viés; Sou um desenvolvedor primeiro, então estou preocupado principalmente em fornecer aos usuários um aplicativo funcional.

Eu trabalhei em sistemas com chaves naturais e tive que gastar muito tempo certificando-me de que as mudanças de valor ocorressem.

Eu trabalhei em sistemas com apenas chaves substitutas, e a única desvantagem foi a falta de dados desnormalizados para particionamento.

A maioria dos desenvolvedores de PL / SQL tradicionais com quem trabalhei não gostava de chaves substitutas por causa do número de tabelas por junção, mas nossos bancos de dados de teste e produção nunca se cansaram; as junções extras não afetaram o desempenho do aplicativo. Com dialetos de banco de dados que não suportam cláusulas como "X junção interna Y em Xa = Yb" ou desenvolvedores que não usam essa sintaxe, as junções extras para chaves substitutas tornam as consultas mais difíceis de ler e mais longas para digitar e verifique: veja a publicação de @Tony Andrews. Mas se você usar um ORM ou qualquer outra estrutura de geração SQL, não perceberá. A digitação por toque também diminui.


Além disso; se você realmente quer dizer que as chaves substitutas são exatamente isso, inicie-as em um número grande aleatório e aumente as seqüências em 3+ e não em 1. Ou use a mesma sequência para gerar valores para mais de uma chave.
WillC

1

Talvez não seja completamente relevante para esse tópico, mas tenho uma dor de cabeça que estou lidando com chaves substitutas. A análise pré-entregue da Oracle cria SKs geradas automaticamente em todas as suas tabelas de dimensões no armazém e também as armazena nos fatos. Portanto, sempre que elas (dimensões) precisarem ser recarregadas à medida que novas colunas são adicionadas ou precisam ser preenchidas para todos os itens na dimensão, os SKs atribuídos durante a atualização os tornam sincronizados com os valores originais armazenados no fato, forçando uma recarga completa de todas as tabelas de fatos que se juntam a ela. Eu preferiria que, mesmo que o SK fosse um número sem sentido, haveria alguma maneira de não mudar para registros originais / antigos. Como muitos sabem, a pronta entrega raramente atende às necessidades de uma organização, e temos que personalizá-lo constantemente. Agora temos dados de 3 anos em nosso armazém, e as recargas completas dos sistemas Oracle Financial são muito grandes. Portanto, no meu caso, eles não são gerados a partir da entrada de dados, mas adicionados em um armazém para ajudar a relatar o desempenho. Entendi, mas a nossa muda, e é um pesadelo.


0

No caso de banco de dados point in time, é melhor ter uma combinação de chaves substitutas e chaves naturais. por exemplo, você precisa rastrear as informações de um sócio de um clube. Alguns atributos de um membro nunca mudam. por exemplo, data de nascimento, mas o nome pode mudar. Portanto, crie uma tabela Membro com uma chave substituta member_id e tenha uma coluna para DOB. Crie outra tabela chamada nome da pessoa e tenha colunas para member_id, member_fname, member_lname, date_updated. Nesta tabela, a chave natural seria member_id + date_updated.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.