Como fazer varios selects em uma só consulta sem utilizar INNER JOIN ou UNION

16/02/2016

6

Ola amigos,

Acabei de fazer meu cadastro aqui.

Bom, tenho a necessidade de selecionar tabelas diferentes com quantidade de campos diferentes, e ainda mais, sem relacionar nenhuma tabela utilizando JOIN e outros.

Preciso listar resultados de quatro tabelas em uma mesma linha ou consulta

Ja tentei utilizando o JOIN mas nao da certo, pois se uma tabela não existir o registro, as outras tabelas nao mostram as informações

(Esta consulta executa mas nao serve devido ao problema em retornar sem nenhum registro caso uma tabela nao existir o dado)

Select
tbClientes.Nome_razao, tbClientes.CPF_CNPJ, tbClientes.Endereco, tbClientes.Cidade, tbClientes.Bairro, tbClientes.UF, tbClientes.CEP, tbClientes.Numero, tbClientes.RG_IE, tbClientes.EstadoCivil, tbClientes.Profissao, tbClientes.Naturalidade,
tbProcessos.Numero_Processo, tbProcessos.Orgao, tbProcessos.Acao, tbProcessos.Vara, tbProcessos.Subacao, tbProcessos.Advogado_Responsavel, tbProcessos.valor_causa, tbProcessos.valor_cobrado, tbProcessos.porcentagem,
tbAdverso.Nome_Razao as Reclamada,
sum(tbFinanceiro.ValorPago) as TotalParcelas, sum(tbFinanceiro.`status`) as ParcPagas, count(tbFinanceiro.`status`) as TotalParc
from tbClientes
INNER JOIN tbProcessos
ON tbProcessos.id = 1340
INNER JOIN tbClientes as tbAdverso
ON tbAdverso.idCliente = 100206055
INNER JOIN tbFinanceiro
ON tbFinanceiro.idProcesso = 1340
where tbClientes.idCliente = 100206054


Preciso de uma consulta que simplesmente em uma linha me retorne os resultados, e se não existir na tabela nao me mostre nada ou me mostre como NULL, porém as outras tabelas devem consultar normalmente independente desta.

Obrigado.
Responder

Post mais votado

16/02/2016

Sempre que postar código utilize a tag <Inserir Código>... isso facilita o entendimento da sua necessidade.

Qualquer gerenciador relacional de banco de dados permite a construção de JOIN com a possibilidade de retorno de linhas nula, ou seja, onde a condição da união não foi observada nas tabelas envolvidas.

Pesquise sobre LEFT JOIN ( ou RIGHT JOIN ) no MySql.
Responder

Mais Posts

16/02/2016

Jothaz

A única forma de listar o conteúdo de várias tabelas relacionadas é usando INNER.

Para resolver o problema citado pesquise e tente aprender mais sobre INNER JOIN, LEFT JOIN, RIGHT JOIN e FULL JOIN.
Responder

16/02/2016

Fernando Alves

Ok usarei as tags.

Ja vi muito a utilização do Left ou Right do INNER JOIN porem nunca coloquei em prática.

Vou ver aqui e retorno, obrigado pela força.

Nao sabia que vcs respondiam rápido assim, hehehe.
Responder

16/02/2016

Fernando Alves

Senhores,

Select perfeito através do LEFT JOIN!


Galera, tive uma economia imensa no processamento, eu teria 4 selects no lugar do LEFT JOIN, eu ja conhecia o INNER JOIN, ja tenho implantado em meus sistemas, mas agora que houve a necessidade de utilizar o LEFT JOIN,

Obrigado Marcos e Jothaz.
Responder
Você poderia usar select dentro do select principal

vamos ver se consigo demonstrar um exemplo
digamos que tenha 4 tabelas


tabelas

cliente            endereco                   municipio                               estado
   - id                 - id                                    - id                                    - id_estado
   - nome           - id_cliente                       - id_estado                        - nome 
                         - id_municipio                   - nome                              - sigla  
                         - logradouro
                         - bairro
                         - cep



Vamos montar um select  

SELECT c.id AS codigoCli,
       c.nome AS nomeCli,
       (SELECT e.logradouro FROM endereco e WHERE id_cliente=c.id ) AS enderecoCli,
       (SELECT e.bairro FROM endereco e WHERE id_cliente=c.id ) AS bairroCli,
       (SELECT e.cep FROM endereco e WHERE id_cliente=c.id ) AS cepCli,
       (SELECT (SELECT m.nome FROM municipio m WHERE id=e.id_municipio ) FROM endereco e WHERE id_cliente=c.id) AS municipio,
       (SELECT (SELECT s.nome FROM estado s WHERE id=e.id_municipio ) FROM endereco e WHERE id_cliente=c.id) AS estado  
        
FROM cliente c


Responder

16/02/2016

Fernando Alves

Verdade, pode ser tambem,

Porem, achei o LEFT JOIN mais facil de aplicar, como estou mais familiarizado.

vlw.
Responder

17/02/2016

Jothaz

DataSAE.

É louvavel sua disposição em ajudar e compartilhar conhecimento e experiência. Não quero ser chato, mas ja estou sendo chato, desmerecer sua ajuda, muito menos iniciar um discussão sem fim.

Mas a sugestão de usar subqueries ao invés de utilizar-se da clausula JOIN não é um boa pratica. Na verdade é um péssima prática e uma tremenda gambiarra.

Claro que existem cenário que devemos utilizar subqueries, mas devemos evitá-las e só usar em casos que não podemos abordar de outra forma.

Além a sua sugestão ser muito mais complicada, se as tabela possuírem grande volume de dados simplesmente a performance vai cair drasticamente e praticamente pode derrubar o servidor.

Qualquer DBA que se preze teria um infarto ao ver este tipo de abordagem.

A pouco tempo um dito DBA aqui da empresa foi despedido por causa de "gambiarra" parecida. Com poucos dados funciona, mas com grandes volumes de dados pode derrubar o server. O que causou um enorme prejuízo a empresa.

Deixo claro que é somente meu ponto de vista sem a pretensão de ser dono da verdade e estou disposto a debater o assunto.

Fernando Alves.

Você esta corretíssimo use o JOIN, além de mais simples e performático e como deve se feito.
Responder

17/02/2016

Marcos P

Concordo com o Jothaz... a performance da solução baseada em subquery, embora funcional, é pavorosa !
Responder
bom saber valeu pela dica
Responder
para mim foi otimo eu ter postado a minha ideia,
e ficar sabendo que não é uma boa pratica e tudo mais.
é que eu tinha entendido que ele não queria usar o join então
passei essa query.

mas não sabia que não é uma boa.

de qualquer forma valeu pela dica
Responder

17/02/2016

Jothaz

A resposta esta correta e funciona, isso é inegável.

Mas tenha em mente que linguagens de programação e banco de dados são laicos, são abertos para que possamos exercer nossa criatividade e construir soluções de acordo com cenários. Dai que podemos resolver um determinado problema de várias forma diferentes e chegarmos a mesmo resultado.

O problema que para qualquer solução será gerado um gasto tempo e processamento e dependendo da solução pode-se ter um custo muito alto o que afeta a performance. No exemplo que dei do camarada que foi despedido era um stored procedure chamada por um WebService usando transação, como deu um erro o WebService tentava desfazer, mas logo em seguida vinha outra requisição do WebService executando outra chamada, foi-se aninhando várias chamadas a SP e ficou na fila de execução o que simplesmente fez o server virar uma carroça.

Só fiz o comentário sobre a resposta por achar que iniciantes podem achar que subqueries são a melhor solução e nem sempre é assim. Ainda mais que temos o JOIN que era a melhor opção. Só o fato de querer usar tabelas relacionais sem um JOIN já é um fato que deve ser abordado.

Sempre digo em TI não temos receitas, mapas ou mesmo certo ou errado, mas temos de nos ater as boas práticas e bom senso. As vezes contrariar as boas praticas é válido só que temos de pesar ser realmente é a melhor solução fazê-lo.

Continue respondendo e compartilhando, pois além de ensinar você acabará aprendendo.


para mim foi otimo eu ter postado a minha ideia,
e ficar sabendo que não é uma boa pratica e tudo mais.
é que eu tinha entendido que ele não queria usar o join então
passei essa query.

mas não sabia que não é uma boa.

de qualquer forma valeu pela dica
Responder

17/02/2016

Fernando Alves

Muito interessante, esta situação sobre a causa de demissão desse seu amigo
DataSAE.

É louvavel sua disposição em ajudar e compartilhar conhecimento e experiência. Não quero ser chato, mas ja estou sendo chato, desmerecer sua ajuda, muito menos iniciar um discussão sem fim.

Mas a sugestão de usar subqueries ao invés de utilizar-se da clausula JOIN não é um boa pratica. Na verdade é um péssima prática e uma tremenda gambiarra.

Claro que existem cenário que devemos utilizar subqueries, mas devemos evitá-las e só usar em casos que não podemos abordar de outra forma.

Além a sua sugestão ser muito mais complicada, se as tabela possuírem grande volume de dados simplesmente a performance vai cair drasticamente e praticamente pode derrubar o servidor.

Qualquer DBA que se preze teria um infarto ao ver este tipo de abordagem.

A pouco tempo um dito DBA aqui da empresa foi despedido por causa de "gambiarra" parecida. Com poucos dados funciona, mas com grandes volumes de dados pode derrubar o server. O que causou um enorme prejuízo a empresa.

Deixo claro que é somente meu ponto de vista sem a pretensão de ser dono da verdade e estou disposto a debater o assunto.

Fernando Alves.

Você esta corretíssimo use o JOIN, além de mais simples e performático e como deve se feito.



Muito interessante esta situação do seu amigo despedido, eu tenho uma aplicação que atende dez clientes em minha cidade, ja faz uns 2 anos que estou implementado recursos novos e coisa e tal, mas existem consultas antigas do tipo select * que me traz colunas em que eu nem preciso, estou tentando aos poucos melhorar a performance, pois não tenho muito tempo para refazer tudo de uma vez. Mas se eu quiser que minha aplicação alcance dezenas de clientes estou ciente de que devo resolver antes estes casos.

Vlw galera, compartilhando conhecimentos.
Responder