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