Existe algum benefício de uma chave primária que inclua todas as colunas da tabela?

Eu tenho uma tabela com quatro colunas que são todas não anuláveis ​​e os dados são tais que todos os quatro são necessários para distinguir um registro exclusivo. Isso significa que, se eu fizesse uma chave primária, ela precisaria incluir todas as colunas. As consultas na tabela quase sempre serão para recuperar um único registro, ou seja, todas as colunas serão filtradas na consulta.

Como todas as colunas precisam ser pesquisadas, ter uma chave primária me beneficia (além de impor a exclusividade dos registros)?

No seu caso, esses campos são naturais chave .

Chave substituta:

Chaves substitutas são chaves que não têm significado "comercial" e são usadas apenas para identificar um registro na tabela. Essas chaves são geradas pelo banco de dados (exemplo: Identidade no SQL Server, Sequência no Oracle, Sequência / Identidade no DB2 UDB etc.) ou valores gerados pelo sistema (como gerados por meio de uma tabela no esquema).

Chave Natural:

As chaves são naturais se o atributo que ele representa for usado para identificação independentemente do esquema do banco de dados. O que isso significa basicamente é que as chaves são naturais se as pessoas as usarem, por exemplo: números de fatura, IDs de imposto, SSN etc.

Chaves substitutas vs Chaves naturais da Chave primária

Prefiro adicionar uma chave substituta para separar o gerenciamento de negócios e de modelo de banco de dados. Outra pergunta é usar o índice clusterizado e não clusterizado na chave primária. Se você alterar as tabelas (tabela não estática, ela possui inserções ou atualizações intensivas), você terá problemas com o desempenho no caso de usar o índice clusterizado na chave aumentada não monotônica.

Geralmente, é recomendável que você tenha uma chave substituta em tais situações, portanto, chaves estrangeiras em outras tabelas (e quaisquer referências de registro que possam ser armazenadas externamente, como se elas forem realizadas em cadeias de consulta em que uma solicitação http (s) se refere a uma dos registros) tem algo a que se referir que não será alterado se os dados na linha forem alterados. Se você fizer isso, essa seria sua chave primária.

Se você não adicionar uma chave substituta, como você descreve os dados que estão acessando, tendo todas as quatro colunas como chave primária, isso não seria uma desvantagem. Se você fizer da chave o índice clusterizado da tabela, ajudará essas solicitações, pois haverá um nível na árvore b no disco para descer para encontrar os dados para uma determinada linha.

Chaves compostas como chaves primárias também apresentam problemas de tamanho de índice que podem afetar o uso do disco, velocidades io e backups. Você pode revisar as postagens de Kimberly Tripp sobre chaves primárias e índices agrupados aqui: http://www.sqlskills.com/BLOGS/KIMBERLY/post/The-Clustered-Index-Debate-again!.aspx

Eu também sugeriria uma chave substituta nesse caso, em vez de uma chave natural.

Se você possui uma tabela que representa um relacionamento muitos-para-muitos com apenas 2 colunas, parece razoável.

Cf. esta pergunta SO

Mas admito que adiciono Chaves Substitutas mesmo nesses casos.