Alexander F. Fernandes - Esc. EDEM wrote: (...)
A consulta?Puxa, mas parecem ser 4 tabelas :)
Tr�s tabelas: medicos, enderecos, especialidades, planos
A consulta:Eu usaria um inner join explicito conforme o SQL-92 (inner join tabela on...) ao inves da sintaxe inner join SQL-89 como a que voce fez. Mas independente disso, *acho* que o inner join foi mal empregado no seu exemplo. Acho que se realizesse 4 selects em separado e as usasse conforme a necessidade do aplicativo ficaria melhor (ficaria sob demanda). Se for um relatorio e n�o d� para fugir do innerjoin, ent�o que pelo menos estabe�a a quantidade de colunas que realmente vai ser usada, duvido que seriam necessarias (em seu exemplo) todas as colunas de todas as tabelas envolvidas. Em tabelas que possuem campos BLOB (Binary Large OBject) que podem armazenar num �nico campo GB de informacoes � terrivel (em todos os sentidos) resgatar tal campo e n�o vir a usa-lo.
select medicos.*, enderecos.*, especialidades.*, planos.* from medicos,enderecos,planos,especialidades where especialidades.id_medico=medicos.id_medico and planos.id_medico=medicos.id_medico and enderecos.id_medico=medicos.id_medico and medicos.id_medico=10;
� algo t�o ruim assim?
Select com * em geral � coisa de programador pregui�oso que n�o se importa com o futuro da aplica��o ou do banco de dados.
A querie mal feita acaba com qualquer servidor SQL, em alguns RDBMS consegue-se o prejuizo � maior.
Eu sempre testaria usando outros bancos de dados na medida do possivel s� para ter uma id�ia de performance e comparativos. No Linux tem o MySQL, Postgre e o Firebird(ex-interbase) onde o MySQL tem menos recursos que os outros. Entao valeria a pena testar, mas acho que justamente pelo MySQL ter menos recursos ele teria (em teoria) melhor performance.
Devo procurar outro banco de dados para fazer essas coisas?
Os relacionamentos n�o v�o ajudar em nada na perfomance nas buscas, mas tenha certeza de ter os indices criados pelo qual os campos estao ligados ou sendo pesquisados.
N�o basta fazer relacionamentos(desconsiderando o desempenho) utilizando as refer�ncias das chaves entre as tabelas(igual ao planos.id_medico=medicos.id_medico)?
[]'s
--------------------------------------------------------------------------- Esta lista � patrocinada pela Conectiva S.A. Visite http://www.conectiva.com.br
Arquivo: http://bazar2.conectiva.com.br/mailman/listinfo/linux-br Regras de utiliza��o da lista: http://linux-br.conectiva.com.br FAQ: http://www.zago.eti.br/menu.html
