7 replies to this topic

[Greg]

Seguinte:

Possuo duas tabelas, uma chamada fitas e outra chamada eventos, onde fitas possui o campo evento_id que é uma FOREIGN KEY de eventos(id).

Possuo uma listagem de todas as fitas, onde realizo a busca da seguinte maneira:

[codebox]
SELECT e.id , e.nome , f.id , f.produtora FROM eventos e , fitas f WHERE e.id = f.evento_id
[/codebox]

Gostaria de saber se é possível otimizar essa busca, uma vez que a quantidade de registros é muito grande.

Valew!

Edição feita por: Greg, 22/04/2008, 10:32.

[boirock]

Grande quanto?

[Greg]

São 945 registros de eventos e 2045 registros de fitas.

[boirock]

Cara, o pior é que não é tanto registro assim... não era pra demorar em condições normais.
Você está exibindo esses dados na tela? A demora é no tempo de resposta do BD ou é pra montar isso na tela para o usuário? Quanto tempo?
Se sim, você realmente precisa mostrar todos esses dados na tela?

Edição feita por: boirock, 22/04/2008, 17:11.

[Greg]

Mostro todos eles na tela, o resultado é paginado, porém é paginado com o tablesorter, que primeiro recebe todos os dados e depois é que pagina os resultados, porém esses dados devem ser todos mostrados, não há como não ser assim.

Valew!

Edição feita por: Greg, 22/04/2008, 17:15.

[boirock]

Aí é que está! Seu problema não é de banco de dados...
Tenho certeza que o tempo de resposta do BD é baixo...
Também, se não for, poste aí o tempo de resposta! Pq aí o buraco é mais embaixo, estrutura ou configuração...

Eu fiz um teste no meu BD (que não é nenhuma Brastemp) com uma situação parecida com a sua... o BD trouxe 15628 linhas em 906 ms.
Rápido né? Não tem o que "tunnar" na query...
Mas se eu mandar o meu front-end exibir todos os registros na tela, provavelmente vai virar uma carroça!

Sei que o tema é polêmico, mas afirmo que você não precisa de todos esses dados na tela. Afirmo com certeza!
Seu usuário não conseguirá jamais lidar com 300 registros ao mesmo tempo, quem dirá com 2045!
Se ele conseguir trabalhar com 200 simultaneamente, ele já será um "herói", concorda?
O usuário não irá até o seu "list" procurando um registro aleatório, irá procurando um determinado registro... certo? Porque ele não pode usar filtro ou paginação feita na query?

Edição feita por: boirock, 22/04/2008, 17:57.

[Greg]

boirock,

devo concordar com você, estou pensando em criar filtros para que ele faça a busca, como letras do alfabeto (dããã!), ou então um campo para ele digitar algo e o sistema retornar todos os resultados parecidos.

Acho que é a melhor solução.

Valew pela luz, até a próxima!

[boirock]

Só pra complementar....
Não sei que linguagem você está utilizando, mas se for pra WEB, um toquezinho de AJAX pode te dar a velocidade que você procura sem perder a usabilidade do sistema.
Basta você mostrar, por exemplo, apenas 10 registros no list. Daí quando o usuário refinar o filtro ou "rolar" o list, você atualiza o list por AJAX.
Soluções existem várias... é só ver qual se encaixa melhor na tua situação!
Precisando, estamos aí!