Bem, o padrão ANSI092 inclui uma sintaxe bastante hedionda. As junções naturais são uma e a cláusula USING é outra. IMHO, a adição de uma coluna a uma tabela não deve quebrar o código, mas um NATURAL JOIN quebra de uma forma flagrante. A "melhor" maneira de quebrar é por erro de compilação. Por exemplo, se você selecionar * em algum lugar, a adição de uma coluna podefalhar ao compilar. A próxima melhor maneira de falhar seria um erro de tempo de execução. É pior porque seus usuários podem ver, mas ainda assim fornece um bom aviso de que você quebrou algo. Se você usar ANSI92 e escrever consultas com junções NATURAL, ele não será interrompido em tempo de compilação e não será interrompido em tempo de execução, a consulta de repente começará a produzir resultados errados. Esses tipos de bugs são insidiosos. Os relatórios dão errado, a divulgação potencialmente financeira está incorreta.
Para quem não está familiarizado com NATURAL Joins. Eles unem duas tabelas em cada nome de coluna que existe em ambas as tabelas. O que é muito legal quando você tem uma chave de 4 colunas e está cansado de digitá-la. O problema surge quando a Tabela1 tem uma coluna pré-existente chamada DESCRIPTION e você adiciona uma nova coluna à Tabela2 chamada, ah, não sei, algo inócuo como, mmm, DESCRIPTION e agora você está juntando as duas tabelas em um VARCHAR2 (1000) campo de formato livre.
A cláusula USING pode levar à ambigüidade total, além do problema descrito acima. Em outra postagem do SO , alguém mostrou este ANSI-92 SQL e pediu ajuda para lê-lo.
SELECT c.*
FROM companies AS c
JOIN users AS u USING(companyid)
JOIN jobs AS j USING(userid)
JOIN useraccounts AS us USING(userid)
WHERE j.jobid = 123
Isso é completamente ambíguo. Eu coloquei uma coluna UserID nas tabelas Empresas e usuários e não há reclamação. E se a coluna UserID nas empresas for o ID da última pessoa a modificar essa linha?
Estou falando sério, alguém pode explicar por que essa ambigüidade foi necessária? Por que ele está embutido no padrão?
Acho que Bill está correto ao dizer que existe uma grande base de desenvolvedores que copiam / colam lá por meio da codificação. Na verdade, posso admitir que sou meio que um quando se trata de ANSI-92. Todos os exemplos que já vi mostravam várias junções aninhadas entre parênteses. Honestamente, isso torna a escolha das tabelas no sql difícil na melhor das hipóteses. Mas então um evangilista SQL92 explicou que isso realmente forçaria uma ordem de junção. JESUS ... todos aqueles Copy pasters que vi agora estão realmente forçando uma ordem de junção - um trabalho que 95% do tempo é melhor deixar para otimizadores, especialmente um copy / paster.
Tomalak acertou quando disse:
as pessoas não mudam para uma nova sintaxe só porque ela está lá
Tem que me dar algo e não vejo um lado bom. E se houver um lado positivo, os negativos são um albatroz grande demais para serem ignorados.