[firebase-br] Chave Primária Composta (Pros/Contra)

[Fernando Oliveira Pereira]

De acordo com os conceitos fundamentais de normalização em banco de dados:
2º FN: *Todo atributo deve ser determinado unicamente pela chave primária.
Se existem atributos que dependem apenas de parte da chave, estes devem ser
separados em tabelas onde a 2NF seja obedecida.*"
3 FN: *Todos os atributos que não são chave sejam mutuamente independentes,
isto é, que não existam funções que definam um ao outro. Isto é, sempre a
chave por inteiro deve definir toda a relação."*

Se criar um campo de índice para determinar a chave da tabela 3, ocorrerá
que o volume depende da prateleira que depende da estante e ambos seriam
campo não chave da tabela. Com relação a desempenho não sei dizer pq não
testei os dois modos ainda, mas estou me baseando em conceitos fundamentais
de BD. =]

Abraço a todos.

Em 04/03/08, Forrest(R) <fernando em gramatura.com.br> escreveu:
>
> Eduardo Bahiense wrote:
>
> > Só uso compostas pelo simples motivo de evitar excesso de metadata.
> > Se três campos determinam a unicidade de um registro, porque devo
> > criar um quarto para servir de chave primária e mais um índice
> > unique, se uma constraint pk resolve.
> > Nossas bases atingem de 3 a 4 GB com mais de 350 tabelas. Não tenho o
> > que reclamar de performance e estabilidade. Nunca tivemos corrupção
> > de base.
> ---
>
> Estou com você Eduardo, não vejo sentido criar um outro campo só para
> ser a chave e ter que criar um indice unique. Utilizo a mesma tecnica
> que você e nunca tive problema.
>
> T++++++++++++++
>
> --
>
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>



-- 
Fernando Oliveira Pereira
Analista & Programador em Sistema de Informação
TiSystems S/S Ltda
Alfenas - MG