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.