RES: [firebase-br] Indices compostos..

eduardo eduardo em icontroller.com.br
Ter Mar 15 09:24:08 -03 2005


Acredito que a questão envolve simplesmente a determinação da real 
identidade de um registro;

Por exemplo, em um sistema de escolas, onde cada escola roda 
isoladamente, mas há a necessidade de se integrar os dados de várias 
escolas em um BD Central (como Secretarias de Educação), a chave da 
Escola deve obrigatoriamente iniciar cada chave primária. Desta forma em 
um cadastro de alunos, a Chave seria Escola,Aluno.
No caso de lançamento de notas, cada Aluno só pode ter um registro para 
cada disciplina, então... Escola, Aluno, Disciplina.

Quando determinamos uma chave única para a tabela, temos que criar 
constraints e índices auxiliares para garantir integridade e performance 
no acesso, quando, algumas vezes, somente a PK composta bastaria para 
satisfazer ambas as necessidades.

Tudo isso deve ser levado em consideração na normalização do Banco.
Acho que PKs compostas devem ser evitadas ao máximo, porém, dentro dos 
limites de praticidade e coerência no ambiente real e não somente  no 
aspecto puro de que para o banco é melhor lidar com PK simples.

É a mesma coisa que dizer que sempre precisamos ter um índice nos campos 
mais utilizados em Selects: Em algumas tabelas, por serem tão pequenas, 
um índice mais atrapalha do que ajuda e o próprio otimizador, algumas 
vezes, opta pela busca natural.

Tudo tem que ser avaliado conforme o caso.


[]'s Eduardo





Mais detalhes sobre a lista de discussão lista