INNER JOIN OU DADOS DIRETO?
Turma do VBManiacos, estou com uma dúvida sobre banco de dados.
Um amigo me falou que quanto mais joins uma consulta tiver mais lento fica, se
for um BD online então é um Deus nos acuda.
Imaginemos uma tabela onde temos as formas de pagamento:
[txt-color=#007100]Avista-Ceque-Cartão de Crédito-Promissória.[/txt-color]
Na tabela de pedidos, seria melhor criar um campo varchar ou char para um
caracter (para avista recebe letra A, promissória P, etc) e no carregamento da
listview fazer um [txt-color=#0000f0]Replace[/txt-color] ou [txt-color=#0000f0]IF[/txt-color] para
mostrar o tipo de venda mesmo? Ou é melhor salvar o código do tipo de venda mesmo e
fazer um Inner Join?
Se bem que essa consulta já possui outros join's então gostaria de saber se evitar isso
seria bom.
Ao meu ver se é para ocupar um campo numérico ou um campo com um caracter é a mesma
coisa ou quem sabe até ocupa menos espaço.
Um amigo me falou que quanto mais joins uma consulta tiver mais lento fica, se
for um BD online então é um Deus nos acuda.
Imaginemos uma tabela onde temos as formas de pagamento:
[txt-color=#007100]Avista-Ceque-Cartão de Crédito-Promissória.[/txt-color]
Na tabela de pedidos, seria melhor criar um campo varchar ou char para um
caracter (para avista recebe letra A, promissória P, etc) e no carregamento da
listview fazer um [txt-color=#0000f0]Replace[/txt-color] ou [txt-color=#0000f0]IF[/txt-color] para
mostrar o tipo de venda mesmo? Ou é melhor salvar o código do tipo de venda mesmo e
fazer um Inner Join?
Se bem que essa consulta já possui outros join's então gostaria de saber se evitar isso
seria bom.
Ao meu ver se é para ocupar um campo numérico ou um campo com um caracter é a mesma
coisa ou quem sabe até ocupa menos espaço.
acredito que dependerá do seu projeto
vai precisar mostrar no financeiro o que foi vendido ou pago agrupado por formas de pagamento?
não vejo que 1 ou 2 join a mais fará tanta diferença assim..
além disso, formas de pgto será uma tabela com poucos registros
vai precisar mostrar no financeiro o que foi vendido ou pago agrupado por formas de pagamento?
não vejo que 1 ou 2 join a mais fará tanta diferença assim..
além disso, formas de pgto será uma tabela com poucos registros
Citação::além disso, formas de pgto será uma tabela com poucos registros
Isso mesmo, mas estou tentando evitar esses joins, minha dúvida é quanto a
ocupação no banco de dados e velocidade nas consultas.
Não sei a causa, motivo, razão ou circunstância que levou seu amigo a dizer isso, o que deixa lento uma query não é a quantidade de join[ô]s que ela contém e sim a estrutura mal elaborada da mesma, falta de index no banco , campos desnecessários na consulta, tunning query nulo, nada de cabeçalhos e estrutura fisica.
Isso vem de mim mesmo quando mexia com [Ô]firebug[Ô] com banco de terceiros e depois eu reproduzindo a mesma consulta com um banco de dados replicado porém com as coisas em seus devidos lugares
uma query que demorava 1 minuto pra correr, corria em milisegundos.
Mysql mesma coisa, ja peguei banco de dados horriveis em que, pasmem o usuario ficava 3 horas executando uma consulta de milhoes de registros para passar as horas mensais de HH pra um outro sistema. Diminui esse tempo total para 20 segundos e ele começou a reclamar que estava trabalhando muito rsss
Isso vem de mim mesmo quando mexia com [Ô]firebug[Ô] com banco de terceiros e depois eu reproduzindo a mesma consulta com um banco de dados replicado porém com as coisas em seus devidos lugares
uma query que demorava 1 minuto pra correr, corria em milisegundos.
Mysql mesma coisa, ja peguei banco de dados horriveis em que, pasmem o usuario ficava 3 horas executando uma consulta de milhoes de registros para passar as horas mensais de HH pra um outro sistema. Diminui esse tempo total para 20 segundos e ele começou a reclamar que estava trabalhando muito rsss
Seu amigo deve ser DBA e assim, pode estar se referindo ao impacto que uma consulta Join causa em relação/comparação com uma consulta [Ô]seca[Ô].
Mas como DBA, ele pode não estar considerando que sem o uso de Joins, ao invés de uma, você terá de fazer várias consultas para chegar ao mesmo objetivo, além do que, terá uma série de [Ô]códigos burros[Ô] para fazer os relacionamentos [Ô]na mão[Ô].
Se as suas consultas Join não chegam à casa das dezenas de milhares de registros por requisição, provavelmente não serão elas as responsáveis por algum problema de performance, mas sim o serviço por onde os dados trafegam.
A outra provável culpada por pêrda de performance é a ausência de normatização (relacionamentos adequados, Ãndices balanceados etc), falha aliás muito comum, e que normalmente é de competência do(s) profissional(is) encarregado(s) por [Ô]traduzir[Ô] a análise do negócio para o storage model.
Mas como DBA, ele pode não estar considerando que sem o uso de Joins, ao invés de uma, você terá de fazer várias consultas para chegar ao mesmo objetivo, além do que, terá uma série de [Ô]códigos burros[Ô] para fazer os relacionamentos [Ô]na mão[Ô].
Se as suas consultas Join não chegam à casa das dezenas de milhares de registros por requisição, provavelmente não serão elas as responsáveis por algum problema de performance, mas sim o serviço por onde os dados trafegam.
A outra provável culpada por pêrda de performance é a ausência de normatização (relacionamentos adequados, Ãndices balanceados etc), falha aliás muito comum, e que normalmente é de competência do(s) profissional(is) encarregado(s) por [Ô]traduzir[Ô] a análise do negócio para o storage model.
Citação:: ao invés de uma, você terá de fazer várias consultas para chegar ao mesmo objetivo..l.
Nesse caso até que não, veja só, digamos que você tenha uma tabela com 3 cidades (somente 3), daÃ
na tabela onde cadastra clientes você tem o campo cidade, você pode cadastrar a cidade diretamente neste
campo ou pode cadastrar o código dela e fazer um inner join quando for consultar.
No primeiro caso não seria feito várias consultas para chegar ao mesmo objetivo pois a informação
já estaria na própria tabela, usaria-se apenas um [txt-color=#0000f0]IF[/txt-color] ou algo assim para mostrar na listview o nome da cidade
caso a gente salvasse nessa tabela apenas uma letra que se referisse a uma das 3 cidades que temos, entendeu?
Essa é a minha dúvida, neste exemplo em si eu não vejo lógica em salvar o código e fazer um Join para
saber qual é a cidade ou qualquer outra coisa uma vez que podemos criar um campo com apenas um carecter
para poupar espaço no BD.
Citação::...ja peguei banco de dados horriveis em que, pasmem o usuario ficava 3 horas executando uma consulta de milhoes de registros para passar as horas mensais de HH pra um outro sistema. Diminui esse tempo total para 20 segundos...
O que você fez (de forma resumida) pra melhorar tanto assim?
3 horas em uma consulta qualquer ser humano daria o sistema por travado e apelaria logo
para são Ctrl + Alt + Del
de forma bem resumida, fiz tunning query. a questão toda era que além da falta de relacionamentos, o banco foi migrado de paradox pra mysql.
ele não dava o sistema como travado pq simplesmente era um cara com seus 60 e poucos anos que não gostava muito de trabalhar e se caso desse algum problema ele jogava a culpa no sistema. Foi ai que essa empresa me contratou e ele passou a me odiar mortalmente kkkkkkkkkk
Ele sempre ficava do lado de fora da sala fumando, tomando café e falava:
- O sistema está processando a consulta.. kkkkkk
foi dureza, passei dias sem dormir, trabalhando em um emprego que tinha e nesse freela, empresa multinacional então era tudo pra já.
no fim das contas deu tudo certo e eles usam o sistema no mundo todo onde tem base deles.
ele não dava o sistema como travado pq simplesmente era um cara com seus 60 e poucos anos que não gostava muito de trabalhar e se caso desse algum problema ele jogava a culpa no sistema. Foi ai que essa empresa me contratou e ele passou a me odiar mortalmente kkkkkkkkkk
Ele sempre ficava do lado de fora da sala fumando, tomando café e falava:
- O sistema está processando a consulta.. kkkkkk
foi dureza, passei dias sem dormir, trabalhando em um emprego que tinha e nesse freela, empresa multinacional então era tudo pra já.
no fim das contas deu tudo certo e eles usam o sistema no mundo todo onde tem base deles.
Citação::Ele sempre ficava do lado de fora da sala fumando, tomando café e falava:
- O sistema está processando a consulta.. .
Meus parabéns, você ganhou um inimigo kkkk
Agora falando sério, parabéns pelo conhecimento e desenvoltura para resolver
tal coisa.
Faça seu login para responder