web-dev-qa-db-fra.com

INSERT vs INSERT INTO

Je travaille avec T-SQL dans MS SQL depuis un certain temps, et chaque fois que je dois insérer des données dans une table, j'ai tendance à utiliser la syntaxe:

INSERT INTO myTable <something here>

Je comprends que le mot clé INTO est facultatif ici et que je ne suis pas obligé de l’utiliser, mais il est devenu une habitude dans mon cas.

Ma question est: 

  • L'utilisation de la syntaxe INSERT par rapport à INSERT INTO a-t-elle des implications?
  • Lequel est conforme à la norme?
  • Sont-ils tous deux valides dans d'autres implémentations du standard SQL?
sqlsql-servertsql
78
kristof

INSERT INTO est la norme. Même si INTO est facultatif dans la plupart des implémentations, il est obligatoire dans quelques-unes. Il est donc judicieux de l'inclure pour vous assurer que votre code est portable.

Vous pouvez trouver des liens vers plusieurs versions du standard SQL ici . J'ai trouvé une version HTML d'un ancien standard ici .

82
Bill the Lizard

C’est la même chose, INTO est complètement facultatif dans T-SQL (d’autres dialectes SQL peuvent différer).

Contrairement aux autres réponses, je pense que l’utilisation de INTO diminue la lisibilité.

Je pense que c'est une chose de conception: dans ma perception, je n'insère pas un row dans un tableau nommé "Client", mais j'insère un Client . (Ceci est lié au fait que je nomme mes tables au singulier et non au pluriel).

Si vous suivez le premier concept, INSERT INTO Customer "se sentirait probablement bien" pour vous.

Si vous suivez le second concept, ce sera probablement INSERT Customer pour vous.

20
Tomalak

Cela peut être facultatif dans MySQL, mais il est obligatoire dans d'autres SGBD, par exemple Oracle. Donc, SQL sera potentiellement plus portable avec le mot clé INTO, pour ce que cela vaut.

10
Tony Andrews

Une leçon que j’ai tirée de cette question est que vous devriez toujours la garder cohérente! Si vous utilisez INSERT INTO, n'utilisez pas non plus INSERT. Si vous ne le faites pas, certains programmeurs peuvent poser à nouveau la même question.

Voici un autre exemple de cas lié: j'ai eu l'occasion de mettre à jour une très longue procédure stockée dans MS SQL 2005. Le problème est que trop de données ont été insérées dans une table de résultats. Je devais trouver d'où venaient les données. J'ai essayé de savoir où de nouveaux disques ont été ajoutés. Au début de la partie SP, j’ai vu plusieurs INSERT INTO. Ensuite, j'ai essayé de trouver "INSERT INTO" et de les mettre à jour, mais j'ai raté un endroit où seul "INSERT" était utilisé. Celui-ci a effectivement inséré 4k + lignes de données vides dans certaines colonnes! Bien sûr, je devrais simplement rechercher INSERT. Cependant, cela m'est arrivé. Je blâme le programmeur précédent IDIOT :) :)

4
David.Chu.ca

Dans SQL Server 2005, vous pourriez avoir quelque chose entre INSERT et INTO comme ceci:

 INSERT top (5) IN ttable1 SELECT * FROM tTable2;

Bien que cela fonctionne sans le INTO, je préfère utiliser INTO pour la lisibilité. 

3
devXen

Ils font tous deux la même chose. INTO est facultatif (dans SQL Server T-SQL) mais facilite la lisibilité.

1
DOK

Si disponible, utilisez la fonction standard. Non pas que vous ayez besoin de la portabilité pour votre base de données particulière, mais il est probable que vous ayez besoin de la portabilité pour votre connaissance SQL .. Un exemple très méchant de T-SQL est l’utilisation de isnull, utilisez coalesce!

0
Tom

J'ai commencé à utiliser SQL sur Oracle, donc quand je vois du code sans INTO, ça a juste l'air 'cassé' et déroutant.

Oui, c'est juste mon opinion, et je ne dis pas que vous devriez utilisez toujours INTO. Cependant, sachez que beaucoup d'autres personnes penseront probablement la même chose, surtout si elles n'ont pas encore commencé à créer des scripts avec de nouvelles implémentations.

Avec SQL, je pense qu’il est également très important de réaliser que vous ajoutez une ligne à une table et que vous ne travaillez pas avec des objets. Je pense qu'il serait inutile pour un nouveau développeur de considérer les lignes/entrées de table SQL comme des objets. Encore une fois, juste moi opinion.

0
Garry_G

Je préfère l'utiliser. Il conserve la même sensation de délimitation de syntaxe et la même lisibilité que d'autres parties du langage SQL, comme group BY, order BY.

0
AgentThirteen