pq usar chave composta?

[horácio 0]

boa tarde a todos!!!

minha dúvida é a seguinte:

qual a razão de usar uma chave composta???

quer dizer , para efeitos de identificação uma primary key não resolve????

usando auto_incremet sempre acontecerá de serem criadas chaves diferente, pois sempre adicionará 1 a chave...aí, teremos registros diferentes sempre...onde entra ( dentro desse contexto) a chave composta????

Obrigado a todos!!

Horácio

[Motta 645]

A pk existe para identificar de forma única o registro.

 

Existem casos em que está identificação se dá por chave dupla.

 

Exemplo : Dependentes de um funcionário

 

funcionario
-----------
matricula (pk)
nome
cpf
salario
datanascimento
...

dependentes
------------
matricula (pk) (fk funcionario)
codigo_dep (pk)
nome
datanascimento
...

[horácio 0]

acho que entendi...seria necessaria para identificar um dado, que é dependente de outro, correto?? mas aí, como seria um select na tabela funcionarios, supondo que o funcionario tenha o PK 12, e o dependente que eu queira encontrar seja o 7?

Obs.: obrigado pela força!!!

Horácio

[Motta 645]

Poderia haver até uma chave artificial (um sequencial) na tabela dependentes, ainda asssim deveria haver alguma coluna ligando o dependete ao funcionário.

[Henrique Barcelos 290]

Na minha humilde opinião, isso daí acaba complicando na hora do acesso aos dados.

O que eu faço normalmente é criar uma PK numérica mesmo, o vulgo 'ID', para toda tabela e fazer essa chave primária virar apenas um indice único.

[William Bruno 1501]

em tabelas de relacionamento esse tipo de coisa não pode ser feito Henrique.

 

criar um ID nesse caso, apenas vai gastar espaço, e ainda assim vai te impossibilitar de atingir o registro q você precisa.

[Henrique Barcelos 290]

Como impossibilita?

Cada dependente possui uma PK única e inteira e para cada usuário também há uma PK única e inteira, ambas geradas com o autoincrement da tabela.

Relacionamos dependente a usuário por uma FK.

 

Espaço? É um inteiro, são 32 bits.

[William Bruno 1501]

estou falando de tabelas de relacionamentos, e não de relacionamentos de tabelas.

antes de achar que os outros estão errados, entenda oque eles estão falando.

 

 

TABLE loja

id, nome

 

TABLE categoria

id, nome

 

TABLE categoria_loja - tabela de relacionamento

id_loja, id_categoria

 

Com essa modelagem podemos ter lojistas multicategorados.

E neste caso, a tabela categoria_loja, não deve ter chave primária.

 

 

Qndo você ver otimização de banco de dados, verá que cada indice e cada escolha "negligenciada como o seu: um inteiro = 32bits" faz bastante diferença no final.

[JCMais 75]

Pelo exemplo que o William passou eu utilizo da forma que ele sugeriu, sem utilizar id em tabelas de relacionamento.

Eu também não costumo usar PK com AutoIncrement quando o relacionamento é 1:1, neste caso uso a FK como PK.

[Henrique Barcelos 290]

estou falando de tabelas de relacionamentos, e não de relacionamentos de tabelas.

Realmente, não li direito... está correto...

[Leonam Dias 0]

Vale lembrar que o "id" é um dado artificial, criado pelo DBA para resolver uma necessidade técnica do sistema. A criação deste em todas as tabelas pode ser perigosa, principalmente em casa onde seja necessária a criação de objetos de resolução, que aqui foi chamada de "tabelas de relacionamento". Incluir um "id" em uma solução dessas poderia gerar quem sabe uma inconsistência no DB e como já foi citado, um atributo a mais em uma tabela onde não há necessidade pode fazer sim diferença.

 

Isso sem falar que para cada chave primária é criado um índice. Imagine a criação de todos estes índices desnecessariamente!

 

Outro uso de chaves compostas: "Objetos históricos"

 

Por exemplo: Seu sistema precisa armazenar determinadas alterações dos usuarios. Neste caso, seria necessário um objeto do tipo "histórico". Dependendo da frequência que isso ocorra, você com certeza vai precisar de um campo de Data fazendo parte da chave para criar poder identificar cada registro.

 

Acredito que este seja um dos melhores exemplos para mostrar a importância e necessidade de chaves primárias compostas!

[Eduardo Ciceri 0]

Concordo na utilização de chaves compostas para tabelas de relacionamento, não vejo sentido em criar uma chave única neste caso. Mas e nos outros casos, na ligação de tabelas um pra muitos? Existe alguma vantagem? Pergunto isso porque entrei em uma empresa recentemente, que trabalha apenas com chaves compostas, por exemplo, uma tabela PEDIDOVENDAITEM, terias 4 campos formando a chave primária: EMPRESAID, FILIALID, PEDIDOVENDAID, PRODUTOID. E por assim vai, já vi tabelas com 7 campos formando a chave única, e isso que acabei de entrar, deve ter casos piores. Existe alguma vantagem em usar neste caso uma chave composta ao invez de utilizar uma chave única? Porque sinceramente considero muito mais simples fazer um update ou um select utilizando apenas um campo e não 4 campos por exemplo.