RES: [firebase-br] Indices compostos..

Alexandre simpsom_boy em yahoo.com.br
Ter Mar 15 10:47:53 -03 2005


Aí vem a velha expressão, "cada caso é um caso", as chaves primárias 
simples ou compostas devem atender as necessidades de cada 
relacionamento entre entidades.

-- 
--------------------------------------------------------------------------------
Alexandre da Silva - Analista de Sistemas
Microsolution - Gestão de Inteligência e Tecnologia
"Francisco Thiago" 
<jeandeadlucky em yahoo.com.br> escreveu na 
mensagem news:003d01c52961$53e17c20$4601a8c0 em bancada11...
> Eu estou com um caso semelhante, só que ao invés de escolas, tenho 
> empresas.
>
> E não uso chaves compostas. Afinal o campo de Empresa é apenas um 
> filtro
> De imediato, não vejo a necessidade de se utilizar uma chave 
> composta... Uso a simples mesmo
>
> Mas não discordo, a análise vista por esse ponto de vista é válida.. é 
> que nem todos os dados (no meu caso) são particulares as empresas... 
> algum são compatilhados (como o cadastro de produtos) e outros não 
> (como o estoque de produtos)
>
> Francisco Thiago de Almeida
> Enter&Plug Informática
> Divisão: Desenvolvimento e Banco de dados
> MSN: thiago em enterplug.com.br
>
> ----- Original Message ----- 
> From: "eduardo" 
> <eduardo em icontroller.com.br>
> To: <lista em firebase.com.br>
> Sent: Tuesday, March 15, 2005 9:24 AM
> Subject: Re: RES: [firebase-br] Indices compostos..
>
>
>> 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
>>
>>
>> ______________________________________________
>> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
>> Para editar sua configuração na lista, use o endereço 
>> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>>
>
>
>
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> Para editar sua configuração na lista, use o endereço 
> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> 







Mais detalhes sobre a lista de discussão lista