Chave primária composta ou não?

Minha humilde opinião leva a frase
“Em time que está ganhando não se mexe”… rs (falo isso quanto a modelagem, não quanto a migraçao do sistema)…
Com um legado tão forte, com tantos dados, fazer uma modificação dessa terá um impacto muito forte, acredito eu.
Por isso acredito que nao valha a pena fazer esse tipo de modificação…

Mas, vejo ser muito utilizada chave primária composta, MUITO mesmo…
Mesmo especialistas usam muito. Pq não é uma boa prática?

Creio que a necessidade deve ser estudada… Ter uma chave composta somente por ter não é válido.

Agora se a tabela for daquelas que a cada dia gera uma nova sequencia, ou um mesmo CPF aparecendo em Ns situações ou Datas diferentes, para cada empresa um novo Número de Identificação que pode ser exatamente o mesmo de uma filial e coisas do tipo… Porque não ?? Tem vezes que não dá pra fugir… Mas fazer por fazer ??? de fato é ruim…

Abs []

Gostaria de acrescentar uma coisa que me parece não ser muito considerada em modelagem. Você precisa de uma chave primária quando terá um relacionamento entre tabelas. Numa tabela você terá registros pai que apontam para registros filho em outra(s) tabelas.
Se você tem uma tabela onde um campo(ou conjunto de campos) que apenas devem cumprir a finalidade de produzirem identificadores únicos você não precisa necessariamente de uma chave primária. Uma constraint do tipo UNIQUE resolve o caso.
Eu convivo com uma aplicação que vem sendo alterada ao longo de muitos anos. Temos de tudo um pouco ali. E temos partes do modelo onde chaves compostas tornaram a manutenção muito difícil. Claro que há casos e casos, mas há um conceito de modelagem interessante chamado surrogate key, que resolve alguns dos problemas trazidos pelas chaves compostas(entre outras coisas).

Se você nunca teve problemas com essa modelagem, não vejo motivos para mudá-la.

Particulamente, não gosto de utilizar chaves compostas quando são feitas a partir de dados editáveis.
Por exemplo: CPF do cliente + Data da Compra.

O problema dessas chaves, é que o usuário tem acesso aos dados, e vira e mexe deseja editá-los.
Não gosto da idéia de mexer em chave primária.

Geralmente uso um id mesmo e não deixo vísivel na aplicação.
Torna minhas queries mais simples (e rápidas) e me dá menos dor de cabeça.

Boa noite a todos.

A chave primaria composta é ideal para as tabelas onde o relacionamento geralmente é de muitos para muitos e em tabelas tuplas.

Mas o que são tabelas tuplas :?:

Voce citar um o meu exemplo, onde numa aplicação chamada Protocolo de documentos, eu tenho uma tabela chamada Documentos e outra chamada Guia de remessa, onde uma guia de remessa pode possuir vários documentos e um documento pode estar em várias guias de remessa. Neste caso se cria uma terceira tabela com somente as chaves estrangeiras da duas tabelas, onde essa tabela se chama a tabela tupla, e nessa tabela, a chave primária obrigatoriamente deve ser composta.

No caso do nosso amigo, o seu sistema deve ter uma tabela que está relacionado a várias outras, onde o há mais de um relacionamento de muitos para muitos, mesmo que não esteja, então voce deverá analisar bem melhor esta modelagem de dados e como todos os outros nossos amigos falaram, time que tá ganhando não se mexe, procure entender melhor a modelagem do antigo sistema, pra voce entender o porque foi feito com a chave composta.

A princípio, a finalidade da chave primária composta, é permitir a duplicação de uma ou da outra chave primária, porém nunca as duas ao mesmo tempo.

Andei estudando melhor sobre o assunto e conclui o seguinte, chave primária composta é ideal para tabelas onde o volume de dados será assustador, para tabelas que não vão receber um número gigante de dados devemos usar o ID mesmo…vou adotar essa estratégia já que realmente a quantidade de registros dessa tabela de documentos fiscais é enorme e cresce em uma proporção grande, ela terá PK composta jah as demais, usarei o ID mesmo…

Agradeço a ajuda de todos suas opiniões foram muito esclarecedoras…Obrigado.

O que você leu que te fez chegar a essa conclusão?

chave composta ao meu ver é uma péssima pratica…
e quase sempre pode ser evitada, porem na sua situação acho que não vale a pena mudar não, é meio arriscado vai causar muito impacto pois a tabela já tem muitos registros a menos que na migração conste tbm em migrar o banco e refazer as tabelas, dai manda bala…

Não gosto de chaves primárias compostas.

Primeiro pq algumas pessoas confundem o conceito (nao estou falando q seja vc ou qm criou o banco). Chave primária composta é a chave primária que utilizar 2 ou mais campos da tabela de forma que TODOS os campos indentifiquem uma tupla INDIVIDUALMENTE.
Por exemplo, a tabela:

Pessoa (Nome, CPF, Endereco)

Nome e CPF NÃO são uma chave primária composta porque, a princípio, posso identificar individualmente uma pessoa pelo seu CPF.

Segundo, pq chaves primárias são índices, e mantê-los (ainda mais compostos) não é de graça.

Terceiro, um int pode sim ser suficiente para vc. No SQL SERVER e no MySQL, um int vai até 2,147,483,647 (quase 2,2 bilhões) - fora a parte negativa que, embora não esteja muito certo, o SGBD usa quando o autonumer dele chega ao limite.

Um índice composto é muito útil se vc tem uma grande quantidade de pesquisar envolvendo TODOS os campos do índice. Por isso, você precisa avaliar se essa chave primária composta é utilizada pela aplicação para realizar esse tipo de busca no BD.

Espero que tenha ajudado! =)

O banco será migrado também.
Lendo a opinião de todos acho melhor criar chave composta apenas para tabelas de relacionamento muitos pra muitos.
Agradeço a opinião de todos…todas me ajudaram muito