Isso, é pra isso que os índices servem.
Dica: Caso uma consulta esteja demorada digite explain SELECT
* FROM pro..
* Esse comando mostra o plano de execução de uma consulta, com a
leitura desse plano é possível identificar índices que podem ser
criados para melhorar a consulta.
Obs: Para quem não sabe, índices indevidos podem prejudicar o
desempenho de uma consulta.
Att,
Henrique de Castro escreveu:
Concordo com o Pedro e também sou a favor de bancos de
dados normalizados. Odeio duplicidade de dados hehe..
E tipo, quanto a desempenho, se vc fizer uma aplicação bem feita,
preocupar com índices, não fazer consultas excessivas, pode ficar
tranquilo que o desempenho está garantido :)
2008/9/18 Pedro <[EMAIL PROTECTED]>
Lógico que tem vantagem, mas
alguém se deparou com a situação: Fazer
relatórios em um banco não normalizado?
Não há consistência nos dados.
=D
Att,
Vinicius Cruz escreveu:
Aumenta a organização, diminui a duplicidade.
Por outro lado, há uma possibilidade de aumento de performance, que é
(a meu ver) o que o cliente mais quer. (Ele pouco se lixa pros nossos
problemas).
Vinicius
2008/9/18 Pedro <[EMAIL PROTECTED]>
O símbolo '=' é um
'join'
implícito, portanto 'inner' e '=' são apenas
duas maneiras diferentes de representar uma mesma instrução, dentro de
cada banco de dados existe um módulo chamado processador de consultas,
que converte instruções SQL para uma nível mais baixo, assim uma mesma
consulta pode ser escrita de várias formas diferentes.
Eu sou a favor de manter o banco mais normalizado possível, as
consultas se tornam mais complexas, mas aumenta a organização e diminui
a duplicidade de dados, entre outras vantagens.
Att,
Vinicius Cruz escreveu:
Pra não perder o foco do email anterior... =)
Sobre o que o Eric falou, "A idéia é manter a modelagem do seu banco da
forma que evite ao máximo a necessidade de se fazer um JOIN.", fiquei
pensando sobre o conceito de normalização no banco de dados, que, de
certa forma, "estimula"o JOIN, não?
A 3º forma normal, por exemplo
http://pt.wikipedia.org/wiki/Banco_de_dados_relacional#Terceira_Forma_Normal_.28FN3.29
Antes de usar o JOIN, eu constumava fazer algo assim:
SELECT * FROM tabela_1 t1, tabela_2 t2 WHERE t1.id=t2.id
Essa forma é menos custosa que o join?
Vinicius
ps.: tenho observado que constantemente tem um pos off-topic. Se
estiver incomodando algum participante da lista, é só falar...
_______________________________________________
Lista mailing list
[email protected]
http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br
--
'É um orgulho ter você como nosso cliente'
____________________________
Pedro Belmino
Desenvolvedor
ArgoHost.net
Hospedagem Web com Facilidade
http://www.argohost.net
Suporte Telefônico: (85) 3264 9944 / (11) 4063 4844
Contato direto: Ramal 107
E-mail: [EMAIL PROTECTED]
_______________________________________________
Lista mailing list
[email protected]
http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br
_______________________________________________
Lista mailing list
[email protected]
http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br
--
'É um orgulho ter você como nosso cliente'
____________________________
Pedro Belmino
Desenvolvedor
ArgoHost.net
Hospedagem Web com Facilidade
http://www.argohost.net
Suporte Telefônico: (85) 3264 9944 / (11) 4063 4844
Contato direto: Ramal 107
E-mail: [EMAIL PROTECTED]
_______________________________________________
Lista mailing list
[email protected]
http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br
_______________________________________________
Lista mailing list
[email protected]
http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br
--
'É um orgulho ter você como nosso cliente'
____________________________
Pedro Belmino
Desenvolvedor
ArgoHost.net
Hospedagem Web com Facilidade
http://www.argohost.net
Suporte Telefônico: (85) 3264 9944 / (11) 4063 4844
Contato direto: Ramal 107
E-mail: [EMAIL PROTECTED]
|
