INSERT so với INSERT INTO

Tôi đã làm việc với T-SQL trong MS SQL một thời gian và bằng cách nào đó bất cứ khi nào tôi phải chèn dữ liệu vào bảng, tôi có xu hướng sử dụng cú pháp:

INSERT INTO myTable <something here>

Tôi hiểu rằng từ khóa INTOlà tùy chọn ở đây và tôi không phải sử dụng nó nhưng bằng cách nào đó nó đã trở thành thói quen trong trường hợp của tôi.

Câu hỏi của tôi là:

• Có bất kỳ hàm ý nào của việc sử dụng INSERTcú pháp so với INSERT INTO?
• Cái nào tuân thủ đầy đủ các tiêu chuẩn?
• Cả hai đều hợp lệ trong các triển khai khác của chuẩn SQL?

INSERT INTOlà tiêu chuẩn. Mặc dù INTOlà tùy chọn trong hầu hết các triển khai, nhưng nó là bắt buộc trong một số ít, vì vậy bạn nên đưa vào để đảm bảo rằng mã của bạn có thể di động.

Bạn có thể tìm thấy các liên kết đến một số phiên bản của tiêu chuẩn SQL tại đây . Tôi đã tìm thấy phiên bản HTML của tiêu chuẩn cũ hơn ở đây .

Chúng giống nhau, INTOlà hoàn toàn tùy chọn trong T-SQL (các phương ngữ SQL khác có thể khác).

Trái ngược với các câu trả lời khác, tôi nghĩ rằng nó làm giảm khả năng đọc khi sử dụng INTO.

Tôi nghĩ đó là một điều đặc biệt: Theo nhận thức của tôi, tôi không chèn một hàng vào bảng có tên "Khách hàng", nhưng tôi đang chèn một Khách hàng . (Điều này liên quan đến thực tế là tôi sử dụng để đặt tên cho các bảng của mình ở số ít, không phải số nhiều).

Nếu bạn làm theo khái niệm đầu tiên, INSERT INTO Customer rất có thể sẽ "cảm thấy phù hợp" với bạn.

Nếu bạn làm theo khái niệm thứ hai, rất có thể nó sẽ INSERT Customerdành cho bạn.

Nó có thể là tùy chọn trong mySQL, nhưng nó là bắt buộc trong một số DBMS khác, ví dụ như Oracle. Vì vậy, SQL sẽ có khả năng di động hơn với từ khóa INTO, cho những gì nó đáng giá.

Một bài học mà tôi rút ra về vấn đề này là bạn nên luôn giữ nó nhất quán! Nếu bạn sử dụng INSERT INTO, đừng sử dụng INSERT cũng như vậy. Nếu bạn không làm điều đó, một số lập trình viên có thể hỏi lại câu hỏi tương tự.

Đây là một trường hợp ví dụ khác có liên quan của tôi: Tôi đã có cơ hội cập nhật một thủ tục được lưu trữ rất dài trong MS SQL 2005. Vấn đề là quá nhiều dữ liệu đã được chèn vào bảng kết quả. Tôi phải tìm xem dữ liệu đến từ đâu. Tôi đã cố gắng tìm ra nơi các bản ghi mới đã được thêm vào. Ở phần đầu của SP, tôi đã thấy một số CHÈN VÀO. Sau đó, tôi cố gắng tìm "CHÈN VÀO" và cập nhật chúng, nhưng tôi đã bỏ lỡ một nơi chỉ sử dụng "CHÈN". Cái đó thực sự đã chèn hơn 4k + hàng dữ liệu trống trong một số cột! Tất nhiên, tôi chỉ nên tìm kiếm INSERT. Tuy nhiên, điều đó đã xảy ra với tôi. Tôi đổ lỗi cho lập trình viên trước đó IDIOT :) :)

Trong SQL Server 2005, bạn có thể có một cái gì đó ở giữa INSERT và INTO như sau:

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

Mặc dù nó hoạt động mà không cần INTO, tôi thích sử dụng INTO hơn để dễ đọc.

Cả hai đều làm điều tương tự. INTO là tùy chọn (trong T-SQL của SQL Server) nhưng hỗ trợ khả năng đọc.

Tôi thích sử dụng nó hơn. Nó duy trì cùng một cảm giác cú pháp phân định và khả năng đọc như các bộ phận khác của ngôn ngữ SQL, như group BY, order BY.

Tôi đã bắt đầu sử dụng SQL trên ORACLE, vì vậy khi tôi thấy mã mà không có INTO, nó trông có vẻ 'bị hỏng' và khó hiểu.

Vâng, đó chỉ là ý kiến ​​của tôi, và tôi không nói rằng bạn nên luôn sử dụng INTO. Nhưng bạn không nên biết rằng nhiều người khác có thể sẽ nghĩ như vậy, đặc biệt là nếu họ chưa bắt đầu viết kịch bản với các triển khai mới hơn.

Với SQL, tôi nghĩ cũng rất quan trọng khi nhận ra rằng bạn ĐANG thêm ROW vào TABLE và không làm việc với các đối tượng. Tôi nghĩ rằng sẽ là vô ích đối với một nhà phát triển mới nếu coi các hàng / mục nhập trong bảng SQL là các đối tượng. Một lần nữa, chỉ cho tôi ý kiến.

Nếu có, hãy sử dụng chức năng tiêu chuẩn. Không phải bạn cần tính di động cho cơ sở dữ liệu cụ thể của mình, nhưng rất có thể bạn cần tính di động cho kiến ​​thức SQL của mình. Một ví dụ T-SQL khó chịu cụ thể là sử dụng isnull, hãy sử dụng kết hợp!