INSERT vs INSERT INTO

Trabalho com T-SQL no MS SQL há algum tempo e, de alguma forma, sempre que preciso inserir dados em uma tabela, costumo usar a sintaxe:

INSERT INTO myTable <something here>

Eu entendo que a palavra INTO- chave é opcional aqui e eu não preciso usá-la, mas de alguma forma ela se tornou um hábito no meu caso.

Minha pergunta é:

• Existem implicações no uso de INSERTsintaxe versus INSERT INTO?
• Qual está em total conformidade com o padrão?
• Ambos são válidos em outras implementações do padrão SQL?

INSERT INTOé o padrão. Embora INTOseja opcional na maioria das implementações, é necessário em algumas, então é uma boa ideia incluí-lo para garantir que seu código seja portátil.

Você pode encontrar links para várias versões do padrão SQL aqui . Encontrei uma versão HTML de um padrão mais antigo aqui .

Eles são a mesma coisa, INTOé totalmente opcional no T-SQL (outros dialetos SQL podem ser diferentes).

Ao contrário das outras respostas, acho que prejudica a legibilidade de uso INTO.

Acho que é uma coisa conceitual: Na minha percepção, não estou inserindo uma linha em uma tabela chamada "Cliente", mas estou inserindo um Cliente . (Isso está relacionado ao fato de que costumo nomear minhas tabelas no singular, não no plural).

Se você seguir o primeiro conceito, INSERT INTO Customerprovavelmente "parecerá certo" para você.

Se você seguir o segundo conceito, provavelmente será INSERT Customerpara você.

Pode ser opcional em mySQL, mas é obrigatório em alguns outros DBMSs, por exemplo Oracle. Portanto, o SQL será potencialmente mais portátil com a palavra-chave INTO.

Uma lição que aprendi sobre esse assunto é que você deve sempre mantê-lo consistente! Se você usar INSERT INTO, não use INSERT também. Se você não fizer isso, alguns programadores podem fazer a mesma pergunta novamente.

Aqui está meu outro caso de exemplo relacionado: Tive a chance de atualizar um procedimento armazenado muito longo no MS SQL 2005. O problema é que muitos dados foram inseridos em uma tabela de resultados. Tive que descobrir de onde vieram os dados. Tentei descobrir onde novos registros foram adicionados. Na seção inicial de SP, vi vários INSERT INTOs. Então tentei encontrar "INSERT INTO" e atualizei-os, mas perdi um lugar onde apenas "INSERT" foi usado. Aquele na verdade inseriu 4k + linhas de dados vazios em algumas colunas! Claro, devo apenas pesquisar INSERT. No entanto, isso aconteceu comigo. Eu culpo o programador anterior IDIOT :) :)

No SQL Server 2005, você poderia ter algo entre INSERT e INTO assim:

INSERT top (5) INTO tTable1 SELECT * FROM tTable2;

Embora funcione sem o INTO, prefiro usar o INTO para facilitar a leitura.

Ambos fazem a mesma coisa. INTO é opcional (no T-SQL do SQL Server), mas ajuda na legibilidade.

Eu prefiro usar. Ele mantém a mesma sensação sintaxe delineação e legibilidade como outras partes da linguagem SQL, como group BY, order BY.

Comecei a wtiting SQL no ORACLE, então quando vejo o código sem INTO parece apenas 'quebrado' e confuso.

Sim, é apenas minha opinião, e não estou dizendo que você deve sempre usar INTO. Mas se você não fizer isso, você deve estar ciente de que muitas outras pessoas provavelmente pensarão a mesma coisa, especialmente se ainda não começaram a criar scripts com implementações mais recentes.

Com SQL eu acho também muito importante perceber que você ESTÁ adicionando uma LINHA a uma TABELA, e não trabalhando com objetos. Acho que não seria útil para um novo desenvolvedor pensar em linhas / entradas de tabelas SQL como objetos. Novamente, apenas minha opinião.

Se disponível, use a função padrão. Não que você precise de portabilidade para seu banco de dados específico, mas é provável que precise de portabilidade para seu conhecimento de SQL. Um exemplo particularmente desagradável de T-SQL é o uso de isnull, use coalesce!