• CHUCK NORRIS não faz DELETEs. Ele olha para os registros e eles correm de medo.
• CHUCK NORRIS não cria PKs. Os registros simplesmente não atrevem-se a duplicar.
• CHUCK NORRIS não usa LOG. Ele lembra de todos registros que alterou.
• CHUCK NORRIS não usa LOG. Ele não vai falhar.
• CHUCK NORRIS não cria INDEXes. Ele sabe que os registros retornarão o mais rápido que puderem.
• CHUCK NORRIS sabe todos os erros do ORACLE de cor. Porque ele criou eles.
• CHUCK NORRIS não faz cursos de ORACLE. A ORACLE é que faz cursos com ele.
• CHUCK NORRIS instala o ORACLE sem ler o manual. (Quem você pensa que é para ter tentado isso?)
• CHUCK NORRIS instala o ORACLE em um 486. Rodando KURUMIM. Em 2 minutos.
• CHUCK NORRIS instala o MSSQL Server em um Pentium 100MHZ. Rodando Solaris. A partis dos fontes.
• CHUCK NORRIS instala o DB2 em um 486. Rodando WINDOWS VISTA. Sem HD.
• CHUCK NORRIS não tem Certificação. São as empresas que tentam tirar Certificação em CHUCK NORRIS. Em vão.
• CHUCK NORRIS tem IGNORE CONTRAINTS automático. Ninguém restringe nada a CHUCK NORRIS. Ninguém.
• CHUCK NORRIS SABE qual o problema de performance do banco. Ele só está dando uma chance do banco se arrepender. 5… 4… 3…
• CHUCK NORRIS não cria STORED PROCEDURES. Todas suas Queries já se armazenam no banco, tentanto se esconder. Mas é inútil.
• CHUCK NORRIS não faz Modelo de Dados. Ele encara o banco até que ele faça o modelo sozinho.
• CHUCK NORRIS instala o ORACLE sem a interface gráfica. E sem a interface texto. (Pergunte a ele você!)
• CHUCK NORRIS não dá DROP TABLE. Ele dá ROUNDHOUSE KICK TABLE.
• MSSQL SERVER É muito mais rápido que ORACLE. Basta que o DBA seja CHUCK NORRIS.
• Uma vez adaptaram o ROUNDHOUSE KICK para o ORACLE. Assim nasceu o TRUNCATE TABLE.
• Uma vez CHUCK NORRIS deu um ROUNDHOUSE KICK em um banco poderoso. Hoje ele é conhecido por ACCESS.
• SELECT SUM (FORÇA) FROM CHUCK_NORRIS; Internal error. Don ‘ t call the support.
• SELECT CHUCK_NORRIS; Drop database sucessful.
• SELECT ROUNDHOUSE_KICK FROM CHUC… Lost connection.
• DELETE FROM CHUCK_NORRIS. Not Found. (Ele está atras de você, a ponto de dar um ROUNDHOUSE KICK!!!)
• Se disser ao DBA CHUCK NORRIS que ” o problema está no banco “, é melhor que esteja se referindo ao Itaú.
• TRIGGERS tem este nome porque CHUCK NORRIS sempre ameaçava atirar no banco quando ele não fazia algo automático.
• Megabyte, Gigabyte, Terabyte, Petabyte, Exabyte, Chuckbite.
• ORACLE tem as versões Personal, Standard, Enterprise e ChuckNorris Edition. Mas nenhum computador é rápido o suficiente para rodá-lo.

Às vezes, mesmo para se fazer uma coisa simples, é necessário um procedimento um pouco mais rebuscado. Já para fazer uma coisa complicada…

O que eu quero fazer não é complicado, mas como eu nunca trabalhei com os INNER, LEFT, RIGHT, OUTER etc., não foi tão trivial assim.

Estou desenvolvendo um pequeno sistema de cobrança (sim, em PHP mesmo!) onde, na listagem de clientes, entre outras coisas, é exibida a cidade e uf a que pertencem.

Até aí, tudo bem! Nada demais. Fiz um JOIN simples:

SELECT cli.*, cid.nome AS nome_cidade, cid.uf
FROM clientes AS cli, cidades AS cid
WHERE cid.id_cidade = cli.cidade

O problema é que, da forma como foi feita, a frase só me retorna os clientes cujo campo cidade esteja preenchido com um valor que conste na tabela cidades. Valores nulos ou inexistentes não retornam os registros.

Uma “solução” (ou seria bacalhau?? [1]) para isso seria não permitir a deleção da cidade na sua tabela, mas isso acaba nos limitando, por diversos motivos.

Eu nunca fiz um JOIN que me retornasse registros desta forma (com os correspondentes nulos ou inexistentes), mas chegara a hora de ter de fazê-lo.

Pesquisando um pouco (foi pouco mesmo!), descobri como fazer um JOIN que me retornasse o que a query acima me retorna:

SELECT * FROM clientes AS cli
INNER JOIN cidades AS cid ON cli.cidade = cid.id_cidade

Bom, até aí, tudo bem! Mas não resolveria o meu problema…

Lembrando um pouco do que eu já tinha lido sobre o tema, vi o “INNER” na frase e lembrei do seu “oposto”: “LEFT OUTER”, que mantém os registros. Logo cheguei à seguinte formulação:

SELECT * FROM clientes AS cli
LEFT OUTER JOIN cidades AS cid ON cli.cidade = cid.id_cidade

Ei-lo como qui-lo! (Ou quase…)

A sentença me retornou todos os campos da tabela de clientes, inclusive aquele registro que tinha o cídogi inválido para a cidade. Agora só faltava manipular os nomes dos campos, por causa da duplicidade (nome do cliente x nome da cidade):

SELECT cli.*, cid.nome AS nome_cidade, cid.uf
FROM clientes AS cli
LEFT OUTER JOIN cidades AS cid ON cli.cidade = cid.id_cidade

Pronto! Estava resolvido o meu problema. E espero que o seu agora também esteja.

Até a próxima!

[1] – O termo provém do antigo ditado que dizia “pra quem é, bacalhau serve”, que era um eufemismo para dizer que, para uma pessoa sem muita importância, uma coisa mal-feita já estava bom. Mas isso era no tempo em que bacalhau e manjubinha disputavam clientes no boteco…