Por que o padrão SQL ANSI-92 não é melhor adotado em relação ao ANSI-89?


107

Em todas as empresas em que trabalhei, descobri que as pessoas ainda estão escrevendo suas consultas SQL no padrão ANSI-89:

select a.id, b.id, b.address_1
from person a, address b
where a.id = b.id

em vez do padrão ANSI-92:

select a.id, b.id, b.address_1
from person a
inner join address b
on a.id = b.id

Para uma consulta extremamente simples como esta, não há uma grande diferença na legibilidade, mas para consultas grandes, acho que ter meus critérios de junção agrupados com a listagem da tabela torna muito mais fácil ver onde posso ter problemas em minha junção, e deixe-me manter toda a minha filtragem na minha cláusula WHERE. Sem mencionar que acho que as junções externas são muito mais intuitivas do que a sintaxe (+) do Oracle.

Enquanto tento divulgar o ANSI-92 para as pessoas, há algum benefício concreto de desempenho no uso do ANSI-92 em vez do ANSI-89? Eu tentaria sozinho, mas as configurações do Oracle que temos aqui não nos permitem usar o EXPLAIN PLAN - não gostaria que as pessoas tentassem otimizar seu código, não é?


7
Uma vantagem principal da notação de junção SQL-92 é que existe uma maneira padrão e relativamente sã de escrever LEFT OUTER JOIN e variantes. Cada DBMS tinha sua própria sintaxe de variante (geralmente ruim; na verdade, eu acho, sem exceção, as notações eram ruins) e frequentemente com semânticas ligeiramente diferentes. O SQL-92 corrigiu isso, e vale a pena usar a nova notação apenas com base nisso. Acho que fica mais claro de qualquer maneira, quando você se acostuma. Demora um pouco para se acostumar, mas não é difícil e, uma vez convertido, não há como voltar atrás.
Jonathan Leffler

semântica, semântica, anti-semântica!
Sam

Estou um pouco atrasado para a festa aqui, mas ninguém parece ter apontado que a própria Oracle recomenda que você use a sintaxe OUTER JOIN da cláusula FROM em vez do operador de junção do Oracle
bornfromanegg

Eu adicionei uma nova resposta que é muito mais atualizada e direta, com clareza sobre outros equívocos nas respostas aqui stackoverflow.com/a/47720615/124486
Evan Carroll

Respostas:


77

De acordo com o "SQL Performance Tuning" de Peter Gulutzan e Trudy Pelzer, das seis ou oito marcas de RDBMS testadas, não houve diferença na otimização ou desempenho do SQL-89 em relação às junções do estilo SQL-92. Pode-se supor que a maioria dos motores RDBMS transformam a sintaxe em uma representação interna antes de otimizar ou executar a consulta, portanto, a sintaxe legível por humanos não faz diferença.

Eu também tento evangelizar a sintaxe SQL-92. Dezesseis anos depois de ser aprovado, é hora de as pessoas começarem a usá-lo! E todas as marcas de banco de dados SQL agora o suportam, então não há razão para continuar a usar a (+)sintaxe Oracle não padrão ou sintaxe *=Microsoft / Sybase.

Quanto ao porquê de ser tão difícil quebrar a comunidade de desenvolvedores do hábito do SQL-89, só posso supor que existe uma grande "base da pirâmide" de programadores que codificam copiando e colando, usando exemplos antigos de livros, artigos de revistas, ou outra base de código, e essas pessoas não aprendem nova sintaxe de forma abstrata. Algumas pessoas combinam com o padrão e outras aprendem mecanicamente.

No entanto, estou gradualmente vendo pessoas usando a sintaxe SQL-92 com mais frequência do que antes. Tenho respondido a perguntas sobre SQL online desde 1994.


6
Eu concordo totalmente. Trabalho com muitos programadores SQL que aprenderam o SQL há 15 anos ou mais (como eu mesmo) e que não sabem nada sobre inovação desde o início. Eles também não têm interesse em descobrir.
Tony Andrews

8
Concorde, mas acrescente que há cenários bem documentados em que a antiga sintaxe de junção ANSI-89 produz resultados incorretos ... especificamente junções externas quando há predicados de filtragem condicional em colunas não relacionadas a junção do lado "externo" da junção.
Charles Bretana

1
Não conheço detalhes internos específicos do MS SQL, mas essa é uma boa evidência anedótica de que a sintaxe do SQL-92 vale a pena. Funciona para mim!
Bill Karwin

2
Enorme? Por favor, poste seu trabalho. Minha melhor aposta é que não é uma comparação igual, mas não responda com "ah, sim, é". Apenas responda com um caso de teste que possamos reproduzir, versão, nível de patch etc.

2
Além disso, a evidência "anedótica" não é uma medida científica de qualquer maneira. É sempre tomado com um grão de sal.
Bill Karwin

16

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.


3
Eu tendo a usar ON porque é menos ambíguo do que USING ou NATURAL JOIN. Quanto aos parênteses, as pessoas que aprenderem "SQL" no Microsoft Access usarão isso como queixas do Access se você omiti-los. (As aspas em torno do SQL devem ser aspas digitais.)
Powerlord

1
Tosse O que é uma cláusula USING? ;-) Eu venho da fração do servidor SQL, então isso não está realmente no meu radar. Como disse o R. Bemrose, tem a cláusula ON funcionando muito bem, nunca me deixando com um join que eu não conseguiria expressar sintaticamente. Não há necessidade de adaptar meu design de banco de dados à sintaxe de consulta para economizar alguma digitação.
Tomalak

3
Se você não conhece seus dados bem o suficiente para usar NATURAL JOIN ou USING quando apropriado, provavelmente não deveria escrever SQL para eles. -1 por ignorância.
Rob

4
IMHO, junções naturais caem no mesmo saco que SELECT *(descobrir que o cliente depende da ordem do campo) - Parece um pouco desleixado
Básico

2
O problema que você descreve com junções naturais é um problema com o design do seu banco de dados - não com o padrão. você deve estar ciente de seus dados e estabelecer padrões para nomes de colunas.
Travis,

14

Algumas razões vêm à mente:

  • as pessoas fazem isso por hábito
  • as pessoas são preguiçosas e preferem as junções do "estilo antigo" porque envolvem menos digitação
  • iniciantes costumam ter problemas para entender a sintaxe de junção do SQL-92
  • as pessoas não mudam para uma nova sintaxe só porque ela está lá
  • as pessoas não estão cientes dos benefícios que a nova sintaxe (se você quiser chamá-la assim), principalmente por permitir que você filtre uma tabela antes de fazer uma junção externa, e não depois dela, quando tudo o que você tem é a cláusula WHERE.

De minha parte, faço todas as minhas junções na sintaxe SQL-92 e converto o código onde posso. É a maneira mais limpa, legível e poderosa de fazer isso. Mas é difícil convencer alguém a usar o novo estilo, quando eles pensam que isso os prejudica em termos de mais trabalho de digitação sem alterar o resultado da consulta.


3
Para muitas pessoas, olhar para o SQL é prejudicial. Alterar qualquer código de trabalho traz o risco de introduzir um bug, especialmente quando o codificador está desviando os olhos. :-)
Bill Karwin

Hm ... para mim, mesmo olhar para expressões regulares complexas não faz mal nenhum. SQL não pode me prejudicar. ;-)
Tomalak

"Iniciantes costumam ter problemas ..." Bem, ESSE é um argumento de venda

2
Por alguma razão, não tenho certeza se esse foi um comentário "pró" ou "contra" ... Talvez meu detector de ironia esteja quebrado.
Tomalak de

10

Em resposta à postagem NATURAL JOIN e USING acima.

POR QUE você veria a necessidade de usar isso - eles não estavam disponíveis em ANSI-89 e foram adicionados para ANSI-92 como o que eu posso ver apenas como um atalho.

Eu nunca deixaria uma junção ao acaso e sempre especificaria a tabela / alias e id.

Para mim, a única maneira de ir é ANSI-92. É mais detalhado e a sintaxe não é apreciada pelos seguidores ANSI-89, mas separa nitidamente suas JOINS de sua FILTRAGEM.


Não vejo NATURAL JOINs como um atalho, mas um Segway em programação de banco de dados orientado a objetos dentro de um banco de dados relacional.
Armand,

5

Primeiro, deixe-me dizer que no SQL Server a sintaxe de junção externa (* =) não fornece resultados corretos o tempo todo. Há momentos em que ele interpreta isso como uma junção cruzada e não uma junção externa. Portanto, há um bom motivo para parar de usá-lo. E essa sintaxe de junção externa é um recurso obsoleto e não estará na próxima versão do SQL Server após o SQL Server 2008. Você ainda poderá fazer junções internas, mas por que alguém iria querer? Eles não são claros e são muito mais difíceis de manter. Você não sabe facilmente o que faz parte da junção e o que é realmente apenas a cláusula where.

Um motivo pelo qual acredito que você não deve usar a sintaxe antiga é que entender as junções e o que elas fazem e o que não fazem é uma etapa crítica para qualquer pessoa que queira escrever código SQL. Você não deve escrever nenhum código SQL sem compreender completamente as junções. Se você os compreender bem, provavelmente chegará à conclusão de que a sintaxe ANSI-92 é mais clara e fácil de manter. Nunca conheci um especialista em SQL que não usasse a sintaxe ANSI-92 em vez da sintaxe antiga.

A maioria das pessoas que conheci ou com quem lidei que usam o código antigo realmente não entende as junções e, portanto, tem problemas ao consultar o banco de dados. Esta é minha experiência pessoal, então não estou dizendo que seja sempre verdade. Mas, como especialista em dados, tive que consertar muito desse lixo ao longo dos anos para não acreditar.


1
Prazer em te conhecer. Feliz por ser o seu primeiro.

4

Aprendi ANSI-89 na escola e trabalhei na indústria por alguns anos. Então eu deixei o fabuloso mundo do DBMS por 8 anos. Mas então eu voltei e esse novo material ANSI 92 estava sendo ensinado. Aprendi a sintaxe Join On e agora ensino SQL e recomendo a nova sintaxe JOIN ON.

Mas a desvantagem que vejo é que as subconsultas correlacionadas não parecem fazer sentido à luz das junções ANSI 92. Quando as informações de junção foram incluídas em WHERE e as subconsultas correlacionadas foram "juntadas" em WHERE, tudo parecia correto e consistente. No ANSI 92, os critérios de junção de tabela não estão em WHERE e a "junção" da subconsulta está, a sintaxe parece inconsistente. Por outro lado, tentar "consertar" essa inconsistência provavelmente só pioraria a situação.


Por outro lado, você p [robaly não deveria estar escrevendo subconsultas correlacionadas, pois elas são devoradoras de desempenho. Eles são como colocar um cursor em sua consulta. Ugh.
HLGEM

3

Não sei a resposta com certeza .. esta é uma guerra religiosa (embora em menor grau do que Mac-Pc ou outros)

Um palpite é que, até bem recentemente, a Oracle (e talvez outros fornecedores também) não adotava o padrão ANSI-92 (acho que era no Oracle v9, ou por aí) e, portanto, para DBAs / Desenvolvedores Db trabalhando em empresas que ainda estavam usando essas versões (ou queriam que o código fosse portátil entre servidores que poderiam usar essas versões, eles tinham que seguir o padrão antigo ...

É realmente uma pena, porque a nova sintaxe de junção é muito mais legível, e a sintaxe antiga gera resultados errados (incorretos) em vários cenários bem documentados.

  • Especificamente, junções externas quando há predicados de filtragem condicional em colunas não relacionadas à junção da tabela no lado "externo" da junção.

Sim, Oracle 9i; lançado em 2001. Um pouco tarde para a festa!

1
MS SQL adicionado INNER JOINem 1995, embora LEFT JOINnão até 1996. O MySQL o tem suportado pelo menos desde 3.23, lançado em 1999; PostgreSQL pelo menos desde 7.2, lançado em 2002. Algumas buscas casuais no Google não me dão resposta para Teradata.

Sim, essa foi a condenação que provou a superioridade da Oracle em 1991: sistemas de banco de dados como o MS access que usavam a sintaxe "Left" e "Right" não eram SQL padrão ANSI. Postar SQL assim foi uma oportunidade para outras pessoas zombarem de você. Mais ou menos como o Twitter e o Facebook agora.
David

2

Inércia e praticidade.

ANSI-92 SQL é como digitar por toque. De alguma forma teórica, pode melhorar tudo algum dia, mas agora posso digitar muito mais rápido olhando para as teclas com quatro dedos. Eu precisaria voltar para ir em frente, sem nenhuma garantia de que algum dia haveria um retorno.

Escrever SQL é cerca de 10% do meu trabalho. Se eu precisar do ANSI-92 SQL para resolver um problema que o ANSI-89 SQL não consegue resolver, irei usá-lo. (Eu uso no Access, na verdade.) Se usar o tempo todo me ajudasse a resolver meus problemas existentes com muito mais rapidez, eu gastaria o tempo para assimilá-lo. Mas posso sacar ANSI-89 SQL sem nunca pensar na sintaxe. Eu sou pago para resolver problemas - pensar na sintaxe SQL é uma perda de tempo e do dinheiro do meu empregador.

Algum dia, jovem Grasshopper, você estará defendendo o uso da sintaxe SQL ANSI-92 contra jovens reclamando que você deveria usar SQL3 (ou qualquer outra coisa). E então você entenderá. :-)


2
A abordagem descrita aqui soa muito como a escola de pensamento "conserte quando quebrar", evitando a ideia de manutenção preventiva. Você é pago para resolver problemas, sim, mas também é pago para agregar mais valor à sua empresa. O ANSI-89 no seu caso oferece maior valor no curto prazo, mas no longo prazo não investir tempo no ANSI-92 será a opção mais cara.
Travis,

Seguir o que você sempre fez tem um custo para o pobre coitado, que precisa manter seu código quando você se ausenta. Isso não significa que você deva mudar para o sabor do mês, mas adotar as melhores práticas quase sempre compensará em sustentabilidade.

Não vou mudar para o Excel (onde você pode fazer qualquer coisa com três cliques do mouse ou menos), porque memorizei os milhares de comandos do Lotus 123 de que preciso e estou confortável para usá-los! Hah!
Charles Bretana

2

Tive uma consulta escrita originalmente para SQL Server 6.5, que não dava suporte à sintaxe de junção do SQL 92, ou seja,

select foo.baz
from foo
  left outer join bar
  on foo.a = bar.a

ao invés foi escrito como

select foo.baz
from foo, bar
where foo.a *= bar.a

A consulta já existia há algum tempo e os dados relevantes se acumulavam para torná-la muito lenta, cerca de 90 segundos para ser concluída. Quando esse problema surgiu, tínhamos atualizado para o SQL Server 7.

Depois de mexer nos índices e outras provocações de Páscoa, alterei a sintaxe de junção para ser compatível com SQL 92. O tempo de consulta caiu para 3 segundos.

Há um bom motivo para mudar.

Repostado a partir daqui .


1

Posso responder do ponto de vista de um desenvolvedor médio, sabendo apenas o SQL o suficiente para entender as duas sintaxes, mas ainda pesquisando a sintaxe exata de insert cada vez que preciso ... :-P (Eu não faço SQL o dia todo , apenas corrigindo alguns problemas de vez em quando.)

Bem, na verdade, acho a primeira forma mais intuitiva, não tornando nenhuma hierarquia aparente entre as duas tabelas. O fato de eu ter aprendido SQL com livros possivelmente antigos, mostrando a primeira forma, provavelmente não ajuda ... ;-)
E a primeira referência que encontro em uma pesquisa sql select no Google (que retorna principalmente respostas em francês para mim ... ) primeiro mostra a forma mais antiga (depois explique a segunda).

Apenas dando algumas dicas sobre a pergunta "por que" ... ^ _ ^ Eu deveria ler um bom livro moderno (agnóstico do DB) sobre o assunto. Se alguém tem sugestões ...


1

Não posso falar por todas as escolas, mas na minha universidade, quando estávamos fazendo o módulo SQL do nosso curso, eles não ensinavam ANSI-92, eles ensinavam ANSI-89 - em um sistema VAX antigo! Não fui exposto ao ANSI-92 até que comecei a vasculhar o Access, tendo construído algumas consultas usando o designer de consulta e, em seguida, vasculhando o código SQL. Percebendo que não tinha ideia de como as junções eram concluídas, ou das implicações da sintaxe, comecei a me aprofundar para entender.

Dado que a documentação disponível não é exatamente intuitiva em muitos casos, e que as pessoas tendem a se apegar ao que sabem e, em muitos casos, não se esforçam para aprender mais do que o necessário para realizar seu trabalho, é fácil ver por que a adoção está demorando tanto.

Claro, existem aqueles evangelistas técnicos que gostam de mexer e entender e tendem a ser aqueles tipos que adotam os princípios "mais novos" e tentam converter o resto.

Estranhamente, parece-me que muitos programadores saem da escola e param de avançar; pensando que porque é isso que eles foram ensinados, é assim que se faz. Só quando você tira os antolhos é que você percebe que a escola foi criada apenas para lhe ensinar o básico e lhe dar compreensão suficiente para aprender o resto sozinho e que na verdade você mal arranhou a superfície do que há para saber; agora é seu trabalho continuar nesse caminho.

Claro, essa é apenas minha opinião com base na minha experiência.


Não são apenas programadores. Em muitos campos, é difícil convencer as pessoas a retreinar depois de estabelecidas em suas carreiras. É claro que existem indivíduos excepcionais, suponho, na mesma proporção em todos os campos.
Bill Karwin

2
É difícil convencer alguém a mudar de algo bem-sucedido para algo diferente que não oferece nenhum benefício. Nosso lado .net da casa mudou de 1,0 para 3,5 e cada etapa intermediária com bajulação ZERO. Cada nova versão era melhor. Não posso dizer o mesmo aqui.

1

1) Forma padrão de escrever OUTER JOIN, versus * = ou (+) =

2) JUNÇÃO NATURAL

3) Depende do mecanismo de banco de dados, as tendências ANSI-92 para serem mais otimizadas.

4) Otimização manual:

Digamos que temos a próxima sintaxe (ANSI-89):

(1)select * from TABLE_OFFICES to,BIG_TABLE_USERS btu
where to.iduser=tbu.iduser and to.idoffice=1

Pode ser escrito como:

(2)select * from TABLE_OFFICES to
inner join BIG_TABLE_USERS btu on to.iduser=tbu.iduser
where to.idoffice=1

Mas também como:

(3)select * from TABLE_OFFICES to
inner join BIG_TABLE_USERS btu on to.iduser=tbu.iduser and to.idoffice=1

Todos eles (1), (2), (3) retornam o mesmo resultado, porém são otimizados de forma diferente, depende do mecanismo de banco de dados, mas a maioria deles:

  • (1) cabe ao mecanismo de banco de dados decidir a otimização.
  • (2) junta as duas tabelas e depois faz o filtro por escritório.
  • (3) filtra o BIG_TABLE_USERS usando o idoffice e depois junta as duas tabelas.

5) Consultas mais longas são menos complicadas.


1

Razões pelas quais as pessoas usam ANSI-89 de minha experiência prática com velhos e jovens programadores e estagiários e recém-formados:

  • Eles aprendem SQL a partir do código existente que veem (em vez de livros) e aprendem ANSI-89 a partir do código
  • ANSI-89 porque é menos digitação
  • Eles não pensam sobre isso e usam um ou outro estilo e nem sabem qual dos dois é considerado novo ou antigo e também não ligam
  • A ideia de que o código também é uma comunicação com o próximo programador que vem mantendo o código não existe. Eles pensam que falam com o computador e o computador não se importa.
  • A arte da "codificação limpa" é desconhecida
  • O conhecimento da linguagem de programação e de SQL especificamente é tão pobre que eles copiam e colam o que encontram em outro lugar
  • Preferência pessoal

Eu pessoalmente prefiro ANSI-92 e altero todas as consultas que vejo na sintaxe ANSI-89 às vezes apenas para entender melhor a instrução SQL em questão. Mas percebi que a maioria das pessoas com quem trabalho não tem habilidade suficiente para escrever junções em muitas tabelas. Eles codificam o melhor que podem e usam o que memorizaram na primeira vez que encontraram uma instrução SQL.


1

Aqui estão alguns pontos comparando SQL-89 e SQL-92 e esclarecendo alguns equívocos em outras respostas.

  1. NATURAL JOINSsão uma ideia horrível. Eles estão implícitos e requerem meta-informações sobre a tabela. Nada sobre o SQL-92 requer seu uso, então simplesmente ignore-os . Eles não são relevantes para esta discussão.
  2. USING é uma ótima ideia, tem dois efeitos:
    1. Ele produz apenas uma coluna no conjunto de resultados de um equijoin.
    2. É uma convenção sólida e sã. No SQL-89, você tinha pessoas escrevendo a coluna idem ambas as tabelas. Depois de unir as tabelas, isso se torna ambíguo e requer aliasing explícito. Além disso, os ids na junção quase certamente tinham dados diferentes. Se você associar pessoa a empresa, terá que criar o alias de um idpara person_ide um idpara company_id, sem os quais a união produziria duas colunas ambíguas. Usar um identificador globalmente exclusivo para a chave substituta da mesa é a convenção com a qual as recompensas padrão USING.
  3. A sintaxe SQL-89 é implícita CROSS JOIN. A CROSS JOINnão reduz o conjunto, ele implicitamente o faz crescer. FROM T1,T2é o mesmo que FROM T1 CROSS JOIN T2, que produz uma junção cartesiana que geralmente não é o que você deseja. Ter a seletividade para reduzir isso a uma WHEREcondicional distante significa que você tem mais chances de cometer erros durante o projeto.
  4. Os s ,explícitos do SQL-89 e do SQL-92 JOINtêm precedências diferentes. JOINtem uma precedência mais alta. Pior ainda, alguns bancos de dados como o MySQL erraram muito por muito tempo. . Portanto, misturar os dois estilos é uma má ideia, e o estilo muito mais popular hoje é o estilo SQL-92.

1) Se você estudar o modelo relacional, perceberá que, além de uma grande ideia ser natural, é o único tipo de união de que você precisa. 2) Veja 1 ie não é necessário. 3) Independentemente da sintaxe (e ambas são sintaxe SQL-92), o operador relacional é produto (multiplicação), isto é, não é realmente uma junção (junção cartesiana 'nem mesmo é uma coisa). 4. Veja 1 ie não é necessário.
dia em

0

A Oracle não implementa bem o ANSI-92. Tive vários problemas, principalmente porque as tabelas de dados no Oracle Apps são muito bem dotadas de colunas. Se o número de colunas em suas junções exceder cerca de 1050 colunas (o que é muito fácil de fazer no Google Apps), você receberá este erro espúrio que não faz absolutamente nenhum sentido lógico:

ORA-01445: cannot select ROWID from a join view without a key-preserved table.

Reescrever a consulta para usar a sintaxe de junção de estilo antigo faz com que o problema desapareça, o que parece apontar a culpa diretamente para a implementação de junções ANSI-92.

Até encontrar esse problema, eu era um defensor constante do ASNI-92, devido aos benefícios de reduzir a chance de uma junção cruzada acidental, o que é muito fácil de fazer com a sintaxe do estilo antigo.

Agora, porém, acho muito mais difícil insistir nisso. Eles apontam para a má implementação da Oracle e dizem "Faremos do nosso jeito, obrigado."


1
Pode ser fácil fazer um Cross Join, também é algo que não acontece espontaneamente e certamente não é ambíguo. Qualquer desenvolvedor SQL decente poderia identificá-lo. Mas USING e NATURAL JOIN são tentadoras que clamam por você e esmagam seu barquinho nas rochas da angústia e da miséria.

1
Meu ponto é, é mais fácil criar com sucesso uma junção cruzada acidental, deixando de fora a cláusula where que une duas tabelas. Uma junção cruzada deve ser deliberada em ANSI-92. Mas eu concordo que NATURAL JOIN é uma abominação. :)
Jonathan

Eu entendi seu ponto. Mas isso não acontece do nada. Conforme você depura sua consulta, percebe o problema e o corrige. Se você usar a junção natural, sem alterações -de modo algum- na própria consulta, ela pode ser alterada devido a uma alteração na tabela.

0

Um novo padrão SQL herda tudo do padrão anterior, também conhecido como 'os grilhões da compatibilidade'. Portanto, o estilo de junção 'antigo' / 'separado por vírgula' / 'não qualificado' é o sytax SQL-92 perfeitamente válido.

Agora, eu argumento que o SQL-92 NATURAL JOINé a única junção de que você precisa. Por exemplo, eu argumento que é superior inner joinporque não gera colunas duplicadas - não há mais variáveis ​​de intervalo nas SELECTcláusulas para eliminar a ambigüidade de colunas! Mas não posso esperar mudar todos os corações e mentes, então preciso trabalhar com programadores que continuarão a adotar o que eu pessoalmente considero estilos de junção legados (e eles podem até se referir a variáveis ​​de intervalo como 'aliases'!). Essa é a natureza do trabalho em equipe e não operar no vácuo.

Uma das críticas à linguagem SQL é que o mesmo resultado pode ser obtido usando uma série de sintaxes semanticamente equivalentes (algumas usando álgebra relacional, outras usando cálculo relacional), onde escolher o 'melhor' simplesmente se resume ao estilo pessoal . Portanto, estou tão confortável com as junções do 'estilo antigo' quanto com INNER. Se eu reservaria um tempo para reescrevê-los, NATURALdepende do contexto.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.