Firebird - Chaves Estrangeiras vs Indices
Boa tarde, estou com uma dúvida devido a um caso "estranho" que encontrei:
Estou analisando o banco de dados de uma empresa e vi que, embora tenha vinculo entre as tabelas, ele não criou nenhuma chave estrangeira para elas. Em alguns casos que os selects com Join começaram a ficar lentos, ele só criou um Índice no campo da tabela.
Quando questionei isso ao cliente, o mesmo me disse que era melhor deixar desse jeito do que criar as chaves estrangeiras, pois o índice era "mais rápido".
Minha dúvida é: A Chave Estrangeira já cria um Índice na tabela, correto? Esse "Índice" seria pior mesmo que um Índice comum?
Teria algum outro motivo para evitar o uso das Chaves Estrangeiras?
Obrigado.
Estou analisando o banco de dados de uma empresa e vi que, embora tenha vinculo entre as tabelas, ele não criou nenhuma chave estrangeira para elas. Em alguns casos que os selects com Join começaram a ficar lentos, ele só criou um Índice no campo da tabela.
Quando questionei isso ao cliente, o mesmo me disse que era melhor deixar desse jeito do que criar as chaves estrangeiras, pois o índice era "mais rápido".
Minha dúvida é: A Chave Estrangeira já cria um Índice na tabela, correto? Esse "Índice" seria pior mesmo que um Índice comum?
Teria algum outro motivo para evitar o uso das Chaves Estrangeiras?
Obrigado.
Diego Martins
Curtidas 0
Melhor post
Dorivan Sousa
30/06/2015
eu nao recordo onde li, mas ja li um artigo onde o autor questionava o uso de chaves estrangeiras falando que elas deixavam o sistema mais lento, nunca testei pra avaliar.
agora com relacao aos indices dependendo do volume de dados da tabelas e do select que é feito vc tem q criar indices para que as consultas fiquem mais rapidas. so nao pode é criar indice pra coluna da tabela pois as inclusoes e alteracoes serao muito lentas.
procure so PLAN do firebird que vai aprender como criar indices mais uteis.
agora com relacao aos indices dependendo do volume de dados da tabelas e do select que é feito vc tem q criar indices para que as consultas fiquem mais rapidas. so nao pode é criar indice pra coluna da tabela pois as inclusoes e alteracoes serao muito lentas.
procure so PLAN do firebird que vai aprender como criar indices mais uteis.
GOSTEI 1
Mais Respostas
Alan Mario
30/06/2015
Olá Diego, tudo bem? Nunca tive contato com o Firebird, então não posso te ajudar muito, mas desconheço qualquer informação sobre o uso de chaves estrangeiras causar uma lentidão.
GOSTEI 1
Dorivan Sousa
30/06/2015
http://ibsurgeonbrasil.blogspot.com.br/p/exemplo-de-como-um-indice-ruim-pode.html
GOSTEI 1
Alan Mario
30/06/2015
O que é pior um indice ruim ou o excesso deles?
GOSTEI 1
Dorivan Sousa
30/06/2015
Isso depende da tabela. Uma tabela com grande volume de entrada de dados e índices desnecessários vai atrapalhar bastante. O negócio é analisar cada caso. Sempre desenvolver com uma base com grande quantidade de dados, o meu BD de testes tem 1gb e tenho tabelas com mais de 1 milhão de registros.
GOSTEI 1
Diego Martins
30/06/2015
Ok. Obrigado pelas dicas e respostas.
Vou tentar melhorar minha dúvida com um exemplo prático do que acontece:
Tabela A -> Clientes (IdCliente Integer, Nome Varchar, etc...)
Tabela B -> Avisos (IdAviso Integer, FK_IdCliente Integer, Assunto Varchar, etc...)
1 Cliente poderá ter vários avisos
Pela regra de relacionamentos e estrutura de bancos, o campo FK_IdCliente deveria ser Chave Estrangeira com Cliente(IdCliente).
Ao invés disso, eles criaram um Indice (FK_IdCliente) acusando de que a Chave Estrangeira atrapalha a performance nesse caso.
Minha dúvida é: qual a vantagem / desvantagem "REAL" em usar um caso ou outro.
Obs: Não só em Firebird, as vezes é bom abstrair o conhecimento a outros pontos.
Obrigado
Vou tentar melhorar minha dúvida com um exemplo prático do que acontece:
Tabela A -> Clientes (IdCliente Integer, Nome Varchar, etc...)
Tabela B -> Avisos (IdAviso Integer, FK_IdCliente Integer, Assunto Varchar, etc...)
1 Cliente poderá ter vários avisos
Pela regra de relacionamentos e estrutura de bancos, o campo FK_IdCliente deveria ser Chave Estrangeira com Cliente(IdCliente).
Ao invés disso, eles criaram um Indice (FK_IdCliente) acusando de que a Chave Estrangeira atrapalha a performance nesse caso.
Minha dúvida é: qual a vantagem / desvantagem "REAL" em usar um caso ou outro.
Obs: Não só em Firebird, as vezes é bom abstrair o conhecimento a outros pontos.
Obrigado
GOSTEI 0
Dorivan Sousa
30/06/2015
como eu disse antes eu ja li artigo falando q a foreing key atrapalha o desempenho. Procurei bastante n achei o artigo. Eu trabalho com um BD sem foreing key e outro com foreing key, isso tanto no Firebird como no postgres e sinceramente não sei dizer se um BD com foreing key tem melhor desempenho em relação ao outro que não tem ou o inverso...hj eu acredito que o correto é utilizar as foreing key, e sempre procurar analisar as consultas que envolvam tabelas de grande volumes de dados ou muitas tabelas. Você n tem como saber se a tabela vai ou n precisar de um determinado índice, somente os sqls q vc vai construí na sua aplicação é que vai determinar isso. E na minha cabeça digo sem conhecimento técnico sobre o assunto uma foreing key é um índice com uma regra de validação.
GOSTEI 1
Alan Mario
30/06/2015
Isso depende da tabela. Uma tabela com grande volume de entrada de dados e índices desnecessários vai atrapalhar bastante. O negócio é analisar cada caso. Sempre desenvolver com uma base com grande quantidade de dados, o meu BD de testes tem 1gb e tenho tabelas com mais de 1 milhão de registros.
Só imagino uma grande quantidade de consultas nesses caso, me parece que deve ter um cuidado especial.
GOSTEI 1