Fórum Performance sem Primary e Foreign Key - vi no site oficial #51213
02/06/2005
0
Segue fragmento retirado do artigo: ´Maximizando a performance do Interbase em aplicativos Delphi/C++Builder´
[size=9:4d0aa0c436]Fonte: www.firebase.com.br - autor não mecionado[/size:4d0aa0c436]
Queria saber de vcs, se este fato é verídico e plausível, pois para mim gerou incertezas, mesmo que esteja vinculado a um dos sites oficiais do FireBird.
Deixar de usar Pk/Fk com este artigo? ... mesmo que a integridade referencial seja feita no braço mesmo?
[size=9:4d0aa0c436]Fonte: www.firebase.com.br - autor não mecionado[/size:4d0aa0c436]
10) Chaves primárias e Extrangeiras, eu não as uso
O Interbase tem meios para que voce declare chaves primárias e secundárias em suas tabelas. Apesar da facilidade que isso oferece, eu não uso nenhum desses meios.
Para chaves primárias, eu uso índices únicos. Isso me permite nomear o índice, e caso algum erro de campo duplicado for gerado, a mensagem de erro exibida conterá o nome do índice o que é mais claro do que rdb$primary. Não bastando isso, índices únicos podem ser desativados e reativados para serem reconstruidos, enquanto as chaves primárias não podem.
Chaves extrangeiras são uma outra estória. Vamos assumir que voce tenha um campo chamado Estado, e que voce queira associar esse campo à uma outra tabela contendo 50 estados em seus registros e portanto voce define uma chave extrangeira para a tabela chamada Estados. Quando voce declara uma foreign key, o IB cria um índice para o campo Estado. O propósito desse índice é o de quando voce tentar apagar um registro na tabela de estados o índice permitirá que o IB rapidamente verifique se o Estado já está sendo usado na tabela relacionada.
O problema da performance está relacionado justamente com o índice que é criado no campo Estado. Se voce tiver 1 milhão de registros em sua tabela e tiver 50 estados diferentes, haverá uma média de 20.000 registros para cada estado, fazendo com que o índice fique muito pobre. Se o optimizador do Interbase resolve utilizar esse índice, poderá haver problemas de performance.
Um lugar onde esse problema estava presente estava rodando um relatório que nunca terminava. Um exame do problema revelou que uma coluna possuia 95.000 registros com o número 3 e 5.000 registros com null. Havia um índice nessa coluna criado por uma foreign key. O optimizador resolveu adotar esse índice e o que ocorreu foi uma desoptimização fazendo com que o relatório levasse até 10 horas para ser gerado. Eliminando a foreign key e substituindo-a por triggers, o tempo para geração do relatório caiu para alguns minutos.
Queria saber de vcs, se este fato é verídico e plausível, pois para mim gerou incertezas, mesmo que esteja vinculado a um dos sites oficiais do FireBird.
Deixar de usar Pk/Fk com este artigo? ... mesmo que a integridade referencial seja feita no braço mesmo?
Nerdex
Curtir tópico
+ 0
Responder
Posts
15/06/2005
Aerreira
Queria saber de vcs, se este fato é verídico e plausível, pois para mim gerou incertezas, mesmo que esteja vinculado a um dos sites oficiais do FireBird.
Deixar de usar Pk/Fk com este artigo? ... mesmo que a integridade referencial seja feita no braço mesmo?
Um pouco de história: [i:2601ea393e]sou da era do bit lascado, quando com TurboBasic tínhamos estruturas de dados feitas à mão sobre arquivos .DAT, tínhamos rotinas para tratamento de índices onde, em cada registro, haviam ponteiros indicando o registro anterior e próximo para as chaves primárias, o resto da ordenação era feito via ´sort´ em memória ou mesmo com mais outros ponteiros no mesmo registro... era o bicho... mas funcionava, faziamos relacionamento entre tabelas, etc.[/i:2601ea393e]
Quanto ao que foi exposto, realmente é possível, mas não concordo pois estariamos retrocedendo no tempo tendo que fazer manualmente algo que o próprio banco já faz automaticamente pra gente. Nos dias de hoje precisamos de produtividade na criação das aplicações, pelo menos eu, não tenho tempo para ficar re-criando algo que já existe. Um bom tunning no banco permitirá as melhorias possíveis... mas nada de ficar re-inventando a roda....
Concordam?[i:2601ea393e][/i:2601ea393e]
Responder
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)