INSÉRER vs INSÉRER DANS

Je travaille avec T-SQL dans MS SQL depuis un certain temps maintenant 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 ce mot-clé INTOest facultatif ici et que je n'ai pas à l'utiliser, mais il est devenu une habitude dans mon cas.

Ma question est:

• Y a-t-il des implications à utiliser la INSERTsyntaxe par rapport à INSERT INTO?
• Lequel est entièrement conforme à la norme?
• Sont-ils tous les deux valides dans d'autres implémentations de la norme SQL?

INSERT INTOest la norme. Même si elle INTOest facultative dans la plupart des implémentations, elle est requise dans quelques-unes, c'est donc une bonne idée de l'inclure pour vous assurer que votre code est portable.

Vous pouvez trouver des liens vers plusieurs versions de la norme SQL ici . J'ai trouvé une version HTML d'une norme plus ancienne ici .

C'est la même chose, INTOc'est complètement optionnel dans T-SQL (les autres dialectes SQL peuvent différer).

Contrairement aux autres réponses, je pense que cela nuit à la lisibilité à utiliser INTO.

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

Si vous suivez le premier concept, INSERT INTO Customervous vous sentirez probablement «bien».

Si vous suivez le deuxième concept, ce serait probablement INSERT Customerpour vous.

Cela peut être facultatif dans mySQL, mais il est obligatoire dans certains autres SGBD, par exemple Oracle. Ainsi, SQL sera plus potentiellement portable avec le mot clé INTO, pour ce qu'il vaut.

Une leçon sur laquelle je me suis penché sur cette question est que vous devez toujours la garder cohérente! Si vous utilisez INSERT INTO, n'utilisez pas INSERT également. Si vous ne le faites pas, certains programmeurs peuvent poser à nouveau la même question.

Voici mon autre exemple de cas connexe: j'ai eu la chance de mettre à jour une procédure stockée très très longue 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 découvrir d'où venaient les données. J'ai essayé de savoir où de nouveaux disques ont été ajoutés. Au début de SP, j'ai vu plusieurs INSERT INTO. Ensuite, j'ai essayé de trouver «INSERT INTO» et de les mettre à jour, mais j'ai manqué un endroit où seul «INSERT» était utilisé. Celui-ci a en fait 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 :) :)

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

INSÉRER top (5) DANS tTable1 SELECT * FROM tTable2;

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

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

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

J'ai commencé à utiliser SQL sur ORACLE, donc quand je vois du code sans INTO, il semble juste «cassé» et déroutant.

Oui, c'est juste mon avis, et je ne dis pas que vous devriez toujours utiliser INTO. Mais si vous ne l'êtes pas, vous devez être conscient que beaucoup d'autres personnes penseront probablement la même chose, surtout si elles n'ont pas commencé à créer des scripts avec des implémentations plus récentes.

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

Si disponible, utilisez la fonction standard. Non pas que vous ayez jamais besoin de portabilité pour votre base de données particulière, mais il y a de fortes chances que vous ayez besoin de portabilité pour vos connaissances SQL. Un exemple particulièrement désagréable de T-SQL est l'utilisation de isnull, use coalesce!