INSERT vs INSERT INTO

Od jakiegoś czasu pracuję z T-SQL w MS SQL i jakoś zawsze, gdy muszę wstawiać dane do tabeli, używam składni:

INSERT INTO myTable <something here>

Rozumiem, że słowo kluczowe INTOjest tutaj opcjonalne i nie muszę go używać, ale jakoś w moim przypadku stało się nawykiem.

Moje pytanie brzmi:

• Czy są jakieś implikacje używania INSERTskładni w porównaniu z INSERT INTO?
• Który z nich jest w pełni zgodny z normą?
• Czy oba są prawidłowe w innych implementacjach standardu SQL?

INSERT INTOto standard. Mimo że INTOjest opcjonalny w większości implementacji, jest wymagany w kilku, więc dobrym pomysłem jest dołączenie go, aby upewnić się, że kod jest przenośny.

Linki do kilku wersji standardu SQL można znaleźć tutaj . Znalazłem wersję HTML starszego standardu tutaj .

Są tym samym, INTOsą całkowicie opcjonalne w T-SQL (inne dialekty SQL mogą się różnić).

W przeciwieństwie do innych odpowiedzi, myślę, że utrudnia to czytelność w użyciu INTO.

Myślę, że to kwestia koncepcyjna: w moim odczuciu nie wstawiam wiersza do tabeli o nazwie „Klient”, ale wstawiam klienta . (Jest to związane z faktem, że używam do nazywania tabel w liczbie pojedynczej, a nie mnogiej).

Jeśli zastosujesz się do pierwszej koncepcji, INSERT INTO Customernajprawdopodobniej „poczujesz się dobrze”.

Jeśli zastosujesz się do drugiej koncepcji, najprawdopodobniej będzie to INSERT Customerdla ciebie.

Może być opcjonalne w MySQL, ale jest obowiązkowe w niektórych innych DBMS, na przykład Oracle. Więc SQL będzie potencjalnie bardziej przenośny ze słowem kluczowym INTO, bez względu na to, ile jest wart.

Jedną z lekcji, na którą się oparłem w tej kwestii, jest to, że zawsze powinieneś zachować spójność! Jeśli używasz INSERT INTO, nie używaj również INSERT. Jeśli tego nie zrobisz, niektórzy programiści mogą ponownie zadać to samo pytanie.

Oto mój inny powiązany przykład: miałem okazję zaktualizować bardzo długą procedurę składowaną w MS SQL 2005. Problem polega na tym, że do tabeli wynikowej wstawiono zbyt wiele danych. Musiałem dowiedzieć się, skąd pochodzą dane. Próbowałem dowiedzieć się, gdzie zostały dodane nowe rekordy. Na początku sekcji SP widziałem kilka INSERT INTO. Potem próbowałem znaleźć „INSERT INTO” i zaktualizowałem je, ale przegapiłem jedno miejsce, w którym użyto tylko „INSERT”. Ten faktycznie wstawił 4k + wierszy pustych danych w niektórych kolumnach! Oczywiście powinienem wyszukać INSERT. Jednak mi się to przytrafiło. Winię za to poprzedniego programistę IDIOTA :) :)

W SQL Server 2005 możesz mieć coś pomiędzy INSERT i INTO, na przykład:

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

Chociaż działa bez INTO, wolę używać INTO dla większej czytelności.

Oboje robią to samo. INTO jest opcjonalne (w języku T-SQL programu SQL Server), ale poprawia czytelność.

Wolę go używać. Utrzymuje same odczucia składnia nakreślenia i czytelność jak inne części języka SQL, jak group BY, order BY.

Zacząłem pisać SQL w ORACLE, więc kiedy widzę kod bez INTO, wygląda to po prostu na „zepsuty” i zagmatwany.

Tak, to tylko moja opinia i nie mówię, że zawsze powinieneś używać INTO. Ale jeśli nie, powinieneś być świadomy, że wiele innych osób prawdopodobnie pomyśli to samo, zwłaszcza jeśli nie zaczęli pisać skryptów z nowszymi implementacjami.

Myślę, że w przypadku SQL jest bardzo ważne, aby zdać sobie sprawę, że dodajesz WIERSZ do TABELI, a nie pracujesz z obiektami. Myślę, że myślenie o wierszach / wpisach tabeli SQL jako o obiektach byłoby nieprzydatne dla nowego programisty. Ponownie, tylko moja opinia.

Jeśli jest dostępna, użyj funkcji standardowej. Nie żebyś kiedykolwiek potrzebował przenośności dla swojej konkretnej bazy danych, ale są szanse, że potrzebujesz przenośności do znajomości języka SQL. Szczególnym nieprzyjemnym przykładem T-SQL jest użycie isnull, użyj coalesce!