INSERT vs INSERT INTO

Ich arbeite seit einiger Zeit mit T-SQL in MS SQL und verwende immer dann, wenn ich Daten in eine Tabelle einfügen muss, die Syntax:

INSERT INTO myTable <something here>

Ich verstehe, dass das Schlüsselwort INTOhier optional ist und ich es nicht verwenden muss, aber irgendwie wurde es in meinem Fall zur Gewohnheit.

Meine Frage ist:

• Gibt es irgendwelche Auswirkungen der Verwendung von INSERTSyntax im Vergleich zu INSERT INTO?
• Welches entspricht voll und ganz dem Standard?
• Sind beide in anderen Implementierungen des SQL-Standards gültig?

INSERT INTOist der Standard. Obwohl dies INTOin den meisten Implementierungen optional ist, ist es in einigen Fällen erforderlich. Daher empfiehlt es sich, es einzuschließen, um sicherzustellen, dass Ihr Code portabel ist.

Sie können Links zu verschiedenen Versionen der SQL - Standards finden Sie hier . Ich habe hier eine HTML-Version eines älteren Standards gefunden .

Sie sind dasselbe, INTOsind in T-SQL völlig optional (andere SQL-Dialekte können abweichen).

Im Gegensatz zu den anderen Antworten beeinträchtigt dies meiner Meinung nach die Lesbarkeit INTO.

Ich denke, es ist eine konzeptionelle Sache: Meiner Meinung nach füge ich keine Zeile in eine Tabelle mit dem Namen "Kunde" ein, sondern einen Kunden . (Dies hängt damit zusammen, dass ich meine Tabellen im Singular und nicht im Plural benenne.)

Wenn Sie dem ersten Konzept folgen, INSERT INTO Customerwürden Sie sich höchstwahrscheinlich "richtig" fühlen.

Wenn Sie dem zweiten Konzept folgen, ist es höchstwahrscheinlich INSERT Customerfür Sie.

In mySQL kann dies optional sein, in einigen anderen DBMS, z. B. Oracle, ist es jedoch obligatorisch. Daher ist SQL mit dem Schlüsselwort INTO potenziell portabler, je nachdem, was es wert ist.

Eine Lektion, die ich zu diesem Thema gelernt habe, ist, dass Sie es immer konsistent halten sollten! Wenn Sie INSERT INTO verwenden, verwenden Sie auch nicht INSERT. Wenn Sie dies nicht tun, stellen einige Programmierer möglicherweise dieselbe Frage erneut.

Hier ist mein weiterer verwandter Beispielfall: Ich hatte die Möglichkeit, eine sehr lange gespeicherte Prozedur in MS SQL 2005 zu aktualisieren. Das Problem ist, dass zu viele Daten in eine Ergebnistabelle eingefügt wurden. Ich musste herausfinden, woher die Daten kamen. Ich habe versucht herauszufinden, wo neue Datensätze hinzugefügt wurden. Am Anfang von SP habe ich mehrere INSERT INTOs gesehen. Dann habe ich versucht, "INSERT INTO" zu finden und sie zu aktualisieren, aber ich habe eine Stelle verpasst, an der nur "INSERT" verwendet wurde. Dieser hat tatsächlich 4k + Zeilen mit leeren Daten in einige Spalten eingefügt! Natürlich sollte ich nur nach INSERT suchen. Das ist mir jedoch passiert. Ich beschuldige den vorherigen Programmierer IDIOT :) :)

In SQL Server 2005 kann zwischen INSERT und INTO Folgendes liegen:

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

Obwohl es ohne INTO funktioniert, bevorzuge ich aus Gründen der Lesbarkeit die Verwendung von INTO.

Sie machen beide dasselbe. INTO ist optional (in T-SQL von SQL Server), verbessert jedoch die Lesbarkeit.

Ich benutze es lieber. Es behält die gleiche Syntax Abgrenzung Gefühl und Lesbarkeit als andere Teile der SQL - Sprache, wie group BY, order BY.

Ich habe angefangen, SQL auf ORACLE zu schreiben. Wenn ich also Code ohne INTO sehe, sieht er einfach 'kaputt' und verwirrend aus.

Ja, es ist nur meine Meinung, und ich sage nicht , Sie sollten immer in Gebrauch. Aber wenn Sie es nicht tun, sollten Sie sich darüber im Klaren sein, dass viele andere Leute wahrscheinlich dasselbe denken werden, insbesondere wenn sie noch nicht mit Skripten mit neueren Implementierungen begonnen haben.

Bei SQL ist es meiner Meinung nach auch sehr wichtig zu erkennen, dass Sie einer TABELLE eine REIHE hinzufügen und nicht mit Objekten arbeiten. Ich denke, es wäre für einen neuen Entwickler nicht hilfreich, sich SQL-Tabellenzeilen / -einträge als Objekte vorzustellen. Wieder nur ich Meinung.

Falls verfügbar, verwenden Sie die Standardfunktion. Nicht, dass Sie jemals Portabilität für Ihre bestimmte Datenbank benötigen, aber wahrscheinlich benötigen Sie Portabilität für Ihre SQL-Kenntnisse. Ein besonders unangenehmes T-SQL-Beispiel ist die Verwendung von isnull, use coalesce!