Fórum Índices de Chaves Estrangeiras #54329
20/12/2005
0
Olá amigos,
Peguei este texto num tópico aqui do forum sobre otimização no Interbase/Firebird:
Se tenho a tabela:
PEDIDO DE VENDA
com chaves
CLIENTE
TRANSPORTADORA
VENDEDOR
Poxa, se o FB cria um índice para cada chave estrangeira isso é bom, certo? Não entendi o por que já que o banco cria um índice para cada Foreign Key isso pode degradar a velocidade das consultas. Geralmente se consulta Pedidos por Vendedor, ou Pedidos por Cliente.
Alguém poderia me explicar?
Vlw pessoALL!
Peguei este texto num tópico aqui do forum sobre otimização no Interbase/Firebird:
Chaves Estrangeiras
-------------------
Chaves estrangeiras são essencialmente restrições de integridade
referencial. O problema com chaves estrangeiras é que elas criarão um
índice na respectiva tabela para facilitar a restrição. Normalmente
isto não é um problema; contudo, se você tem uma restrição de chave
estrangeira em colunas que tendem a não ter valores únicos, então você
tem um índice bastante pobre. Se o otimizador de consultas utilizar um
desses índices, isto causará um gargalo devido à pobreza dos índices.
Nestes casos, remover os índices pode melhorar a performance das
consultas em 100¬. Então tenha cuidado quando você definir suas chaves
estrangeiras.
Se tenho a tabela:
PEDIDO DE VENDA
com chaves
CLIENTE
TRANSPORTADORA
VENDEDOR
Poxa, se o FB cria um índice para cada chave estrangeira isso é bom, certo? Não entendi o por que já que o banco cria um índice para cada Foreign Key isso pode degradar a velocidade das consultas. Geralmente se consulta Pedidos por Vendedor, ou Pedidos por Cliente.
Alguém poderia me explicar?
Vlw pessoALL!
Romulocpd
Curtir tópico
+ 0
Responder
Posts
20/12/2005
Romulocpd
Olá Pessoal,
Po, sei lá, fiquei meio bolado com aquele artigo
Vejam este:
Beleza, entendi. Mas como resolver?
Tenho na tabelad e PEDIDO DE VENDA os campos
PED_EMPRESA
PED_CODIGO
onde o pedido é referenciado a uma empresa, por ser um sistema multi-empresa.
Eu enteido, mas como faria no meu caso? ou nao poderia fazer?
Vlw!
Po, sei lá, fiquei meio bolado com aquele artigo
Vejam este:
Chaves Primárias
----------------
Se você definir uma chave primária composta, mais que um índice é criado
(um para cada coluna que compõe a chave). Como o otimizador de consultas
usará os múltiplos índices para resolver a consulta, isto pode causar um
gargalo para o otimizador, já que os múltiplos índices usados pelo
otimizador são iguais aos campos da consulta.
Beleza, entendi. Mas como resolver?
Tenho na tabelad e PEDIDO DE VENDA os campos
PED_EMPRESA
PED_CODIGO
onde o pedido é referenciado a uma empresa, por ser um sistema multi-empresa.
Eu enteido, mas como faria no meu caso? ou nao poderia fazer?
Vlw!
Responder
Gostei + 0
20/12/2005
Afarias
|Poxa, se o FB cria um índice para cada chave estrangeira isso é bom,
|certo?
CORRETO!
|Não entendi o por que já que o banco cria um índice para cada Foreign
|Key isso pode degradar a velocidade das consultas.
*pode* ocorrer quando o índice não possui boa seletividade. isso não é frequente em chaves estrangeiras mas é bom estar atento.
um índice de baixa seletividade é um índice em uma coluna onde o cunjunto de valores possíveis é pequeno (em relação à quantidade de registros) -- por exemplo uma coluna q só pode ter 5 valores diferentes
|Geralmente se consulta Pedidos por Vendedor, ou Pedidos por Cliente.
Imagine (num sistema pequeno) que depois de 1 ano vc tem ai uns 40.000 pedidos. Desses 40.000 cada cliente participou em média de uns 400. Isso quivale a 1¬ dos registros, sendo assim, vc tem ai uma seletividade muito boa no campo CLIENTE.
|Se você definir uma chave primária composta, mais que um índice é
|criado (um para cada coluna que compõe a chave).
Não sei onde vc pegou esse texto, mas note que a forma interna de trabalho com índices e chaves é diferente para cada banco de dados.
Essa informação ai por exemplo não é correta para o FB ou IB.
O IB/FB cria 1 índice apenas COMPOSTO para as chaves COMPOSTAS.
|Como o otimizador de consultas usará os múltiplos índices para resolver
|a consulta, isto pode causar um gargalo para o otimizador,
Essa é outra informação que não é adequada para o IB/FB. É verdade que alguns bancos preferem índices compostos, mas não é o caso do IB/FB.
O otimizador do IB/FB trabalha melhor com 2 índices com apenas 1 campo cada do que com 1 índice composto contendo os 2 campos.
|Tenho na tabelad e PEDIDO DE VENDA os campos PED_EMPRESA
|PED_CODIGO onde o pedido é referenciado a uma empresa, por ser um
|sistema multi-empresa.
Veja, particularmente não gosto de trabalhar com chaves compostas. Acredito que tornam tudo mais difícil -- mas isso é particular.
Quanto aos índices vc pode testar para ver com que opção vc consegue melhor performance. Mas eu acredito aqui q ter 2 índices (1 para PED_EMPRESA e outro para PED_CODIGO) deva ser a melhor opção.
Quanto à unicidade dessas 2 informações, pode ser realizada usando uma trigger BEFORE INSERT e BEFORE UPDATE
Mas note q cada projeto tem suas particularidades, não há uma regra geral. Vc deve conhecer bem seu sistema e o banco de dados, então, procurar projetar da melhor forma para atender seus requisitos. Fazer testes em áreas mais críticas tb é sempre uma opção.
T+
|certo?
CORRETO!
|Não entendi o por que já que o banco cria um índice para cada Foreign
|Key isso pode degradar a velocidade das consultas.
*pode* ocorrer quando o índice não possui boa seletividade. isso não é frequente em chaves estrangeiras mas é bom estar atento.
um índice de baixa seletividade é um índice em uma coluna onde o cunjunto de valores possíveis é pequeno (em relação à quantidade de registros) -- por exemplo uma coluna q só pode ter 5 valores diferentes
|Geralmente se consulta Pedidos por Vendedor, ou Pedidos por Cliente.
Imagine (num sistema pequeno) que depois de 1 ano vc tem ai uns 40.000 pedidos. Desses 40.000 cada cliente participou em média de uns 400. Isso quivale a 1¬ dos registros, sendo assim, vc tem ai uma seletividade muito boa no campo CLIENTE.
|Se você definir uma chave primária composta, mais que um índice é
|criado (um para cada coluna que compõe a chave).
Não sei onde vc pegou esse texto, mas note que a forma interna de trabalho com índices e chaves é diferente para cada banco de dados.
Essa informação ai por exemplo não é correta para o FB ou IB.
O IB/FB cria 1 índice apenas COMPOSTO para as chaves COMPOSTAS.
|Como o otimizador de consultas usará os múltiplos índices para resolver
|a consulta, isto pode causar um gargalo para o otimizador,
Essa é outra informação que não é adequada para o IB/FB. É verdade que alguns bancos preferem índices compostos, mas não é o caso do IB/FB.
O otimizador do IB/FB trabalha melhor com 2 índices com apenas 1 campo cada do que com 1 índice composto contendo os 2 campos.
|Tenho na tabelad e PEDIDO DE VENDA os campos PED_EMPRESA
|PED_CODIGO onde o pedido é referenciado a uma empresa, por ser um
|sistema multi-empresa.
Veja, particularmente não gosto de trabalhar com chaves compostas. Acredito que tornam tudo mais difícil -- mas isso é particular.
Quanto aos índices vc pode testar para ver com que opção vc consegue melhor performance. Mas eu acredito aqui q ter 2 índices (1 para PED_EMPRESA e outro para PED_CODIGO) deva ser a melhor opção.
Quanto à unicidade dessas 2 informações, pode ser realizada usando uma trigger BEFORE INSERT e BEFORE UPDATE
Mas note q cada projeto tem suas particularidades, não há uma regra geral. Vc deve conhecer bem seu sistema e o banco de dados, então, procurar projetar da melhor forma para atender seus requisitos. Fazer testes em áreas mais críticas tb é sempre uma opção.
T+
Responder
Gostei + 0
20/12/2005
Romulocpd
Afarias,
Muito obrigado pela explicação e também por sua opinião que é muito importante.
Este texto eu peguei aqui mesmo nofórum.
Veja vc mesmo.
[url]
http://forum.clubedelphi.net/viewtopic.php?t=55948&highlight=guia+performance
[/url]
Vlw kra!
Muito obrigado pela explicação e também por sua opinião que é muito importante.
Este texto eu peguei aqui mesmo nofórum.
Veja vc mesmo.
[url]
http://forum.clubedelphi.net/viewtopic.php?t=55948&highlight=guia+performance
[/url]
Vlw kra!
Responder
Gostei + 0
20/12/2005
Afarias
|Este texto eu peguei aqui mesmo nofórum.
OK 8)
T+
OK 8)
T+
Responder
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)