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