ВСТАВИТЬ против ВСТАВИТЬ В - PullRequest
80 голосов
/ 24 октября 2008

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

INSERT INTO myTable <something here>

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

Мой вопрос:

  • Существуют ли какие-либо последствия использования синтаксиса INSERT против INSERT INTO?
  • Какой из них полностью соответствует стандарту?
  • Они оба действительны в других реализациях стандарта SQL?

Ответы [ 9 ]

84 голосов
/ 24 октября 2008

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

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

20 голосов
/ 24 октября 2008

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

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

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

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

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

10 голосов
/ 24 октября 2008

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

4 голосов
/ 24 октября 2008

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

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

3 голосов
/ 25 марта 2009

В SQL Server 2005 между INSERT и INTO может быть что-то вроде этого:

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

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

1 голос
/ 24 октября 2008

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

0 голосов
/ 10 февраля 2017

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

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

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

0 голосов
/ 25 октября 2008

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

0 голосов
/ 24 октября 2008

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...