Подтвердить что ты не робот

INSERT против INSERT INTO

Я работаю с T-SQL в MS SQL в течение некоторого времени, и как-то всякий раз, когда мне приходится вставлять данные в таблицу, я предпочитаю использовать синтаксис:

INSERT INTO myTable <something here>

Я понимаю, что ключевое слово INTO является необязательным здесь, и мне не нужно его использовать, но как-то оно стало привычным в моем случае.

Мой вопрос:

  • Есть ли какие-либо последствия использования синтаксиса INSERT в сравнении с INSERT INTO?
  • Какой из них полностью соответствует стандарту?
  • Являются ли они действительными в других реализациях стандарта SQL?
4b9b3361

Ответ 1

INSERT INTO является стандартом. Несмотря на то, что INTO является необязательным в большинстве реализаций, требуется несколько, поэтому рекомендуется включить его, чтобы убедиться, что ваш код переносимый.

Здесь вы можете найти ссылки на несколько версий SQL здесь. Я нашел HTML-версию более старого стандарта здесь.

Ответ 2

Это то же самое, INTO полностью необязательно в T-SQL (другие диалекты SQL могут отличаться).

Вопреки другим ответам, я считаю, что это затрудняет использование INTO.

Я думаю, что это концептуальная вещь. По моему мнению, я не вставляю строку в таблицу с именем "Клиент", но я вставляю клиента. (Это связано с тем, что я использую для обозначения своих таблиц в единственном числе, а не во множественном числе).

Если вы следуете первому понятию, INSERT INTO Customer, скорее всего, "почувствует себя хорошо" для вас.

Если вы следуете второму понятию, это скорее всего будет INSERT Customer для вас.

Ответ 3

Он может быть необязательным в mySQL, но он необходим в некоторых других СУБД, например Oracle. Таким образом, SQL будет более потенциально переносимым с ключевым словом INTO, для чего он стоит.

Ответ 4

Один урок, на который я склонялся, состоит в том, что вы всегда должны держать его в покое! Если вы используете INSERT INTO, не используйте INSERT. Если вы этого не сделаете, некоторые программисты могут снова задать тот же вопрос.

Вот мой другой пример, связанный с примером: у меня была возможность обновить очень длинную хранимую процедуру в MS SQL 2005. Проблема заключается в том, что в таблицу результатов было добавлено слишком много данных. Мне нужно было выяснить, откуда пришли данные. Я попытался выяснить, где были добавлены новые записи. В начале раздела SP я увидел несколько INSERT INTO. Затем я попытался найти "INSERT INTO" и обновил их, но я пропустил одно место, где использовался только "INSERT". На самом деле это вставляло 4k + строки пустых данных в некоторые столбцы! Конечно, я должен просто искать INSERT. Однако это случилось со мной. Я обвиняю предыдущего программиста IDIOT:):)

Ответ 5

В SQL Server 2005 у вас может быть что-то между INSERT и INTO следующим образом:

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

Хотя он работает без INTO, я предпочитаю использовать INTO для удобочитаемости.

Ответ 6

Они оба делают то же самое. INTO является необязательным (в SQL Server T-SQL), но поддерживает читаемость.

Ответ 7

Я предпочитаю использовать его. Он поддерживает те же синтаксические разграничения и читаемость, что и другие части языка SQL, такие как group BY, order BY.

Ответ 8

Если доступно, используйте стандартную функцию. Не то, чтобы вам когда-либо понадобилась переносимость для вашей конкретной базы данных, но, скорее всего, вам нужна переносимость для ваших знаний SQL. Особым неприятным примером T-SQL является использование isnull, использование coalesce!

Ответ 9

Я начал использовать SQL на ORACLE, поэтому, когда я вижу код без INTO, он просто выглядит "сломанным" и запутанным.

Да, это просто мое мнение, и я не говорю, что вы всегда должны использовать INTO. Но вы не знаете, что многие другие люди, вероятно, подумают об одном и том же, особенно если они не начали писать сценарии с новыми реализациями.

С SQL я думаю, что очень важно понять, что вы добавляете ROW в TABLE и не работаете с объектами. Я думаю, что новому разработчику было бы бесполезно думать о строках/записях SQL-таблиц как о объектах. Опять же, только мнение.