Posted on: March 05, 2024 11:24 AM

Posted by: Renato

Categories: sql mysql database dba inteligenciadedados

Views: 144

Quando é recomendado o uso de chave primária composta?

Uma chave simples é associada a um único valor, ou campo, do registro. Uma chave composta corresponde à combinação de duas ou mais chaves, e pode ser necessária para eliminar a ambiguidade, formando um identificador único. (Wikipedia)

Vamos supor, apenas como exemplo, que eu vá implementar um blog com o uso de chave primária simples. Os registros ficariam assim:

Tabela posts:
| id |     post     |
-------------------
|  1 | "Um post"    |
|  2 | "Outro post" |

Tabela comentarios:
| id | post_id |    comentario    |
---------------------------------
|  1 |       1 | "Meu comentário" |
|  2 |       1 | "Meu comentário" |
|  3 |       1 | "Meu comentário" |
|  4 |       2 | "Meu comentário" |
|  5 |       2 | "Meu comentário" |
|  6 |       2 | "Meu comentário" |

Ou seja: os comentários teriam chaves primárias (coluna id) únicas em relação a todos os comentários, mesmo de outros posts.

Se eu usasse chave primária composta os comentários teriam id's únicos apenas com relação ao seu post (coluna post_id):

Tabela comentarios:
| post_id | id |    comentario    |
---------------------------------
|       1 |  1 | "Meu comentário" |
|       1 |  2 | "Meu comentário" |
|       1 |  3 | "Meu comentário" |
|       2 |  1 | "Meu comentário" |
|       2 |  2 | "Meu comentário" |
|       2 |  3 | "Meu comentário" |

O mesmo princípio vale para outras situações, como uma nota fiscal e seus itens, por exemplo.

Em que situações é recomendado o uso da chave primária composta? E quando é melhor usar chave primária simples?

No seu caso acredito que seu campo comentário deve ter seu próprio id e deve ter o o post_id sendo usado como chave estrangeira, assim como no caso das notas fiscais, já que nesses casos você está falando de um relacionamento 1xN (um comentário pertence a um, e apenas um post, já o post possui 0 ou muitos comentários).

O uso de chave primária composta pode ser feito quando você possui dois campos que juntos sempre serão únicos para aquela tabela, por exemplo:

Em um determinado aeroporto saem voos todos os dias, o número dos voos é sempre o mesmo para um determinado horário e um determinado destino, por exemplo, o voo com destino a Guarulhos no horário das 20:00 é de numero 1212. Independente do dia, o voo 1212 sempre será com o destino a Guarulhos e sempre no horário das 20:00, logo você não pode usar voo como chave primária, nem mesmo data, pois em um mesmo dia saem inúmeros voos. Nesse caso você poderia usar os campos voo e data como chaves primárias, pois eles juntos são únicos, já que nunca terá o mesmo voo duas vezes em um mesmo dia.

| voo  |    data    | outros campos...
--------------------------------------
| 1212 | 14/05/2014 |
| 1234 | 14/05/2014 | 
| 2345 | 14/05/2014 | 
| 1212 | 15/05/2014 |
| 1234 | 15/05/2014 | 
| 2345 | 15/05/2014 | 

Você também poderia atribuir um id para cada registro e usar uma única chave primária, entretanto isso depende da sua modelagem.

Transcrevendo tudo que foi dito nos comentários:
Me arrisco a dizer que para todos os casos que a situação se assemelhe com a tabela fictícia de voos, você poderá optar tanto por usar duas colunas como chave primária composta ou por criar um id e ter uma chave primária simples.

Diferenças:

• Optando por usar duas colunas como chave primária você economiza um campo na sua tabela, e também você já está adicionando uma constraint a sua tabela garantindo a consistência dos dados. A desvantagem nesse caso é ter que usar dois campos em toda operação que você fizer que necessita pegar um único registro, como select, update, delete, etc. Outra desvantagem é que para cada tabela relacional que você fizer, terá um campo a mais, logo a primeira vantagem que eu citei acaba não compensando essa desvantagem, já que uma tabela relacional costuma ter muito mais registros do que as tabelas que ela relaciona.

• Optando por usar o id, fica mais fácil fazer os relacionamentos com outras tabelas, pois você usará apenas um campo sempre. A desvantagem é que você terá um campo a mais em sua tabela. Outro ponto que não é desvantagem nem vantagem é que você terá que colocar os constraints a parte, indicando quais campos são únicos, vale lembrar que é possível dizer que dois campos juntos são únicos, similar a uma chave primária composta.

Na maioria dos casos, as vantagens e desvantagens de cada são quase desconsideráveis, portanto escolha a opção que você ficar mais a vontade.

Só consegui imaginar um caso em que uma opção seria melhor do que a outra, seria se seu modelo tiver muitos relacionamentos NxN, pois a quantidade de campos aumentaria de uma forma considerável, mais ainda se ao invés de dois campos você tiver inúmeros campos como chave primária, para cada tabela você possuirá uma quantidade muito superior de campos e dados.

Respondendo a dúvida inicial em usar ou não usar PK composta. Por experiência eu aprendi levando porrada que não é bom utilizar chave composta.

Podemos citar como exemplo para utilizar PK única:

• Banco de dados que tenham campos identity (auto sequencial) é mais fácil de utulizar
• Fazer update / delete no where é mais fácil e rápido (imagina você ter que usar 10 campos no where
• Mais fácil visualizar em outras tabelas
• inner join e left join são mais fácil e rápido de fazer

O único motivo para uma chave composta seria numa tabela N:N, porém neste casos, prefiro fazer uma PK única, e o constrain para validar os outros campos.

Chave composta deve ser usada se e somente se você quiser garantir a integridade referencial no seu banco de dados de que nunca existirá uma combinação igual destas chaves para um registro na mesma tabela.

Eu confesso que posso garantir essa integridande utilizando indices compostos únicos e nunca precisei recorrer às PK compostas. Pois no fim isso adiciona complexidade na hora de consultar e um manipular um registro.

Outro ponto que pode ser levado em conta aqui é a indexação mais rápida se voce quiser por exemplo economizar joins utilizando uma consulta em uma das chaves ou indices compostos mas isso poderia ser feito com FKs assim como PKs compostas.

Sinceramente, eu recomendo nunca utilizar.

Espero ter ajudado.

Fonte:

https://pt.stackoverflow.com/questions/15883/quando-%c3%a9-recomendado-o-uso-de-chave-prim%c3%a1ria-composta

Renato

Developer