Esta não é uma questão sobre os benefícios ou não de usar uma chave de incremento automático artificial em qualquer tabela em vez de usar uma 'chave primária' de vários campos. Essa discussão (ou argumento) pode ser facilmente encontrada e as decisões tomadas por quem quiser procurá-las.
Esta questão é mais sobre o desempenho das chaves (ou falta delas)
Trabalho como gerenciador de banco de dados e, quando crio minhas tabelas, tento usar uma chave 'natural' para a tabela. Muitas vezes, isso sai como um conjunto de 2,3 ou, às vezes, 4 campos que atuam como a chave primária para a tabela fornecida. Na maioria das vezes, esses campos são Varchar por natureza, mas curtos (10 ou 15 caracteres no máximo). Pessoalmente, tento mantê-los mais curtos!
Minha pergunta é esta.
Imagine que eu tenho uma tabela que contém dados demográficos. A única maneira de garantir que tenho exclusividade em cada linha é usar os campos para FirstName FamilyName DateOfBirth PlaceOfBirth
(Você pode se perguntar por que incluí 'local de nascimento', estou ciente de outro indivíduo (que morava perto - mesmo número de telefone, código de discagem diferente) com quem compartilhei todos esses detalhes (suponho que o PlaceOfBirth era diferente, mas acho que poderia ter usado MothersMaidenName ;) )
então agora eu tenho um problema interessante.
Eu poderia usar um campo muito mais curto que é criado a partir da concatenação das informações nos 4 campos principais exemplo: DateOfBirth primeiros 2 caracteres de FirstName primeiros 2 caracteres de FamilyName primeiros 2 caracteres de PlaceOfBirth
Minha pergunta é esta.
Em que ponto a concatenação do campo forneceria uma melhoria de desempenho em relação ao uso dos campos diretamente, ou seja, quantas colunas.
Eu sei pela pesquisa que a maioria dos DBMS tem um 'limite de tamanho máximo teórico' dependente da árvore B que é criada. Estou assumindo que não atingi esse limite em termos de comprimento/tamanho da chave primária.
Meu motivo para considerar o uso desse tipo de chave 'inventada' é: as informações na coluna concatenada provavelmente são suficientes para identificar o registro sem a necessidade de extrair todos os campos de chave primária (isso seria melhor para desempenho ou não diferente em comparação com o uso de todos os 4 campos de chave primária?)
Obviamente, essa é uma questão bastante "teórica", mas considerei fazer essa concatenação em uma tabela que termina com 4 campos varchar e era óbvio que a exclusividade seria descrita usando apenas uma versão abreviada. Obviamente há um esforço para criar esse campo em primeiro lugar, mas em outras opiniões esse esforço valeria a pena e em que ponto ele se tornaria mais interessante.
Eu procurei por isso, mas nunca encontrei essa pergunta feita diretamente, ela sempre aparece como uma discussão de chave primária 'natural' ou 'artificial'.
Claro, se isso parece uma discussão-chave 'natural' ou 'artificial', sinta-se à vontade para dizê-lo. Meu sentimento é que essa chave 'inventada' ofereceria as vantagens de ambos. Alguém já usou essa ideia em uma solução do mundo real?
Agradecemos antecipadamente por seus pensamentos.
Davi
Editar. Acabei de encontrar este tópico
https://stackoverflow.com/questions/3735390/best-primary-key-for-storing-urls
Parece cobrir um terreno semelhante, devo admitir que não tinha pensado em 'misturar' minhas colunas (principalmente porque são curtas por natureza), mas gosto da ideia. Eu acho que você poderia fazer isso e hash toda a linha!
Editar2.
Voltei a esta pergunta apenas para ver se houve alguma alteração nas respostas ou comentários extras. Decidi aceitar uma resposta, mas gostaria de observar que achei todas as respostas úteis nos termos da discussão.
Vou responder obliquamente...
A chave natural é sempre a chave natural e deve ser aplicada com uma restrição ou índice exclusivo. Esta é a "chave primária" que flui de sua fase de modelagem .
A escolha de uma chave substituta de número/identidade automática é importante na fase de implementação porque há escolhas boas e ruins para seu índice clusterizado (exemplo: SQL Server, Sybase, MySQL InnoDB, Oracle IOT).
Ou seja, a chave primária é ortogonal ao seu índice clusterizado: não confunda os dois problemas
Sugiro que o uso de uma chave artificial não agregue valor em relação ao uso de uma coluna de número/identidade automática a esse respeito. Você perde dados da chave natural, provavelmente não será único, é igualmente opaco.
FWIW, eu uso chaves substitutas e chaves compostas quando preciso também:
Nota: isso pressupõe que toda tabela requer um índice clusterizado
Relacionado em dba.se: Decisão de design de chave primária/índice clusterizado do SQL Server
Em minha própria experiência, toda vez que me deparo com uma dessas chaves artificiais, embora possa parecer uma boa ideia no papel, elas sempre causaram problemas. Essencialmente, é uma forma de desnormalização se a família muda, ou seja, alguém se casa ou se divorcia, agora você muda em ambos ou perde como foi planejado. A menos que eu esteja sob a mira de uma arma, sempre escolho a integridade dos dados em vez do desempenho.
Seria uma arquitetura de banco de dados realmente horrível usar chaves compostas ou usar uma chave composta concatenada como você propõe. Para chaves compostas, quaisquer tabelas com uma referência de chave estrangeira para seus dados demográficos também exigiriam colunas para apontar para FirstName FamilyName DateOfBirth PlaceOfBirth.
Concatenar os dados em uma coluna é uma péssima ideia - você usará VARCHAR(~256) para suas referências de Chave Primária e Chave Estrangeira. Isso tornará seus índices enormes e o desempenho será prejudicado. Você também precisará analisar e unir para obter os dados reais - isso é propenso a erros, pois Kevin Andersen New York não é o mesmo que Kevin Andersen New York.
Você deve usar uma chave substituta - uma chave que não tem contexto em seu modelo de negócios (long/bigint ou GUID).
Veja o modelo de dados do Facebook:
https://graph.facebook.com/cocacola
observe que o ID é uma chave substituta representada por um número que não tem contexto nos dados - 40796308305