INSERT เทียบกับ INSERT INTO


91

ฉันทำงานกับ T-SQL ใน MS SQL มาระยะหนึ่งแล้วและเมื่อใดก็ตามที่ฉันต้องแทรกข้อมูลลงในตารางฉันมักจะใช้ไวยากรณ์:

INSERT INTO myTable <something here>

ฉันเข้าใจว่าคำหลักINTOนั้นเป็นตัวเลือกที่นี่และฉันไม่จำเป็นต้องใช้ แต่อย่างใดมันก็กลายเป็นนิสัยในกรณีของฉัน

คำถามของฉันคือ:

  • มีความหมายของการใช้INSERTวากยสัมพันธ์INSERT INTOหรือไม่?
  • ข้อใดเป็นไปตามมาตรฐานอย่างครบถ้วน
  • ทั้งสองอย่างถูกต้องในการใช้งานมาตรฐาน SQL อื่น ๆ หรือไม่?

คำตอบ:


96

INSERT INTOเป็นมาตรฐาน แม้ว่าจะINTOเป็นทางเลือกในการใช้งานส่วนใหญ่ แต่ก็จำเป็นต้องใช้ในบางส่วนดังนั้นจึงควรรวมไว้เพื่อให้แน่ใจว่าโค้ดของคุณเป็นแบบพกพา

คุณสามารถค้นหาเชื่อมโยงไปยังหลายรุ่นมาตรฐานของ SQL ที่นี่ ผมพบว่าในเวอร์ชัน HTML มาตรฐานเก่าที่นี่


2
หนังสือ "SQL-99 Complete, Really" กล่าวว่า Sybase (และด้วยเหตุนี้ MS SQL Server) จึงทำงานในลักษณะที่ไม่เป็นมาตรฐานทำให้ INTO เป็นทางเลือก ฐานข้อมูลยี่ห้ออื่นต้องใช้คีย์เวิร์ด
Bill Karwin

2
ขวา. หากคุณใช้ INTO เสมอคุณไม่จำเป็นต้องจำว่าอันไหนคิดว่าเป็นทางเลือก การใช้งานทั้งหมดอนุญาตให้ใช้
Bill the Lizard

22

เป็นสิ่งเดียวกันINTOเป็นทางเลือกโดยสมบูรณ์ใน T-SQL (ภาษาถิ่น SQL อื่นอาจแตกต่างกัน)

ขัดกับคำตอบอื่น ๆ INTOผมคิดว่ามันบั่นทอนการอ่านกับการใช้งาน

ฉันคิดว่ามันเป็นสิ่งที่ปฏิสนธิ: ในการรับรู้ของฉันฉันไม่ได้แทรกแถวลงในตารางที่มีชื่อว่า "ลูกค้า" แต่ฉันใส่ลูกค้า (สิ่งนี้เชื่อมโยงกับการที่ฉันใช้ตั้งชื่อตารางเป็นเอกพจน์ไม่ใช่พหูพจน์)

หากคุณทำตามแนวคิดแรกINSERT INTO Customerมักจะ "เหมาะสม" สำหรับคุณ

หากคุณทำตามแนวคิดที่สองก็น่าจะINSERT Customerเหมาะกับคุณมากที่สุด


5
ฉันคิดว่าความเสี่ยงในแนวทางของคุณคือคุณอาจทำให้โปรแกรมเมอร์มือใหม่สับสนออบเจ็กต์กับตารางได้
Dave DuPlantis

12
คำตอบของคุณถูกต้องตามความเป็นจริง เป็นเรื่องที่น่าเสียดายเมื่อผู้คนลงคะแนนมุมมองของฝ่ายตรงข้าม ฉันคิดว่าประโยชน์อย่างหนึ่งของ SO คือการรับฟังความคิดเห็นที่แตกต่างกัน
DOK

ไม่ใช่เรื่องของการคิดในวัตถุและตาราง เป็นการคิดในเชิงแนวคิดเป็นแบบจำลองเชิงสัมพันธ์เอนทิตี
Andre Figueiredo

@DaveDuPlantis อ่า Jackie Treehorn เข้าใจผิด +1
ruffin

10

อาจเป็นทางเลือกใน mySQL แต่จำเป็นต้องมีใน DBMS อื่น ๆ เช่น Oracle ดังนั้น SQL จะพกพาได้ง่ายขึ้นด้วยคำหลัก INTO สำหรับสิ่งที่คุ้มค่า


4

บทเรียนหนึ่งที่ฉันได้เรียนรู้เกี่ยวกับปัญหานี้คือคุณควรทำให้สอดคล้องกันเสมอ! หากคุณใช้ INSERT INTO อย่าใช้ INSERT เช่นกัน หากคุณไม่ทำโปรแกรมเมอร์บางคนอาจถามคำถามเดิมอีกครั้ง

นี่คือกรณีตัวอย่างอื่นที่เกี่ยวข้องของฉัน: ฉันมีโอกาสอัปเดตโพรซีเดอร์ที่เก็บไว้นานมากใน MS SQL 2005 ปัญหาคือข้อมูลถูกแทรกในตารางผลลัพธ์มากเกินไป ฉันต้องหาว่าข้อมูลมาจากไหน ฉันพยายามค้นหาว่ามีการเพิ่มระเบียนใหม่ที่ไหน ในส่วนเริ่มต้นของ SP ฉันเห็น INSERT INTO หลายรายการ จากนั้นฉันพยายามค้นหา "INSERT INTO" และอัปเดต แต่ฉันพลาดที่เดียวที่ใช้เฉพาะ "INSERT" อันนั้นจริงแทรกข้อมูลเปล่า 4k + แถวในบางคอลัมน์! แน่นอนฉันควรค้นหา INSERT อย่างไรก็ตามที่เกิดขึ้นกับฉัน ฉันตำหนิโปรแกรมเมอร์คนก่อน IDIOT :) :)


ดูเหมือนว่าผู้เขียนสร้างด้วย INSERT INTO และบางคนใส่ INSERT ในการบำรุงรักษา มันเกิดขึ้นมากมายมากกว่าที่ "ควร" อย่างน่าเสียดาย
Andre Figueiredo

3

ใน SQL Server 2005 คุณอาจมีบางอย่างอยู่ระหว่าง INSERT และ INTO ดังนี้:

แทรกด้านบน (5) เข้าไปใน tTable1 SELECT * จาก tTable2;

แม้ว่าจะใช้งานได้โดยไม่มี INTO แต่ฉันชอบใช้ INTO เพื่อให้อ่านง่าย


1

ทั้งสองทำสิ่งเดียวกัน INTO เป็นทางเลือก (ใน T-SQL ของ SQL Server) แต่ช่วยในการอ่าน


0

ฉันชอบใช้มันมากกว่า มันจะเก็บความรู้สึกไวยากรณ์การวาดภาพเหมือนกันและการอ่านเป็นส่วนอื่น ๆ ของภาษา SQL เช่น,group BYorder BY


0

ฉันเริ่ม wtiting SQL บน ORACLE ดังนั้นเมื่อฉันเห็นโค้ดที่ไม่มี INTO มันก็ดู 'เสีย' และสับสน

ใช่มันเป็นเพียงความคิดเห็นของฉันและฉันไม่ได้บอกว่าคุณควรใช้ INTO เสมอไป แต่คุณไม่ควรทราบว่าคนอื่น ๆ อาจจะคิดแบบเดียวกันโดยเฉพาะอย่างยิ่งหากพวกเขายังไม่ได้เริ่มเขียนสคริปต์ด้วยการใช้งานที่ใหม่กว่า

ด้วย SQL ฉันคิดว่าสิ่งสำคัญมากที่จะต้องตระหนักว่าคุณกำลังเพิ่ม ROW ลงในตารางและไม่ทำงานกับวัตถุ ฉันคิดว่ามันคงไม่เป็นประโยชน์สำหรับนักพัฒนาใหม่ที่จะคิดว่าแถว / รายการตาราง SQL เป็นวัตถุ อีกครั้งเพียงแค่ฉันความคิดเห็น


0

หากมีให้ใช้ฟังก์ชันมาตรฐาน ไม่ใช่ว่าคุณต้องการความสามารถในการพกพาสำหรับฐานข้อมูลเฉพาะของคุณ แต่มีโอกาสที่คุณจะต้องพกพาเพื่อความรู้ SQL ตัวอย่าง T-SQL ที่น่ารังเกียจโดยเฉพาะคือการใช้ isnull ใช้ coalesce!

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.