ตัวจัดรูปแบบ/ปรับแต่ง SQL

ตัวจัดรูปแบบ/ปรับแต่ง SQL เป็นเครื่องมือฟรีที่รับโค้ด SQL แล้วจัดรูปแบบใหม่ให้อ่านง่ายและมีโครงสร้างสม่ำเสมอขึ้น

การจัดรูปแบบ SQL เปลี่ยนอะไรบ้าง?

การจัดรูปแบบ SQL จะปรับการนำเสนอคำสั่งค้นหา เพื่อให้อ่านส่วนคำสั่ง นิพจน์ และโครงสร้างที่ซ้อนกันได้ง่ายขึ้น โดยทั่วไปจะเพิ่มการขึ้นบรรทัดใหม่และการเยื้องให้กับองค์ประกอบต่าง ๆ เช่น รายการ SELECT, ส่วนคำสั่ง JOIN, เงื่อนไข WHERE, คำสั่งค้นหาย่อย และนิพจน์ CASE

การจัดรูปแบบไม่ควรเปลี่ยนผลลัพธ์ที่คำสั่งค้นหาต้องการให้เกิดขึ้น อย่างไรก็ตาม SQL แต่ละภาษาถิ่นมีความแตกต่างกัน และการจัดรูปแบบเพียงอย่างเดียวไม่สามารถยืนยันได้ว่าคำสั่งยังคงมีความหมายเดิม ตรวจสอบ SQL ที่สร้างขึ้นก่อนนำไปรันกับข้อมูลในระบบใช้งานจริง โดยเฉพาะเมื่อมีตัวดำเนินการเฉพาะของผู้ให้บริการ ส่วนขยายเชิงกระบวนคำสั่ง หรือกฎการใช้อัญประกาศที่ไม่เป็นปกติ

เครื่องมือจัดรูปแบบมีประโยชน์เมื่อต้องอ่านคำสั่งค้นหาจากบุคคลอื่น ตรวจสอบ SQL ที่ระบบสร้างขึ้น แก้จุดบกพร่องในคำสั่งยาว ๆ หรือเตรียมโค้ดสำหรับ pull request รูปแบบที่สม่ำเสมอยังช่วยให้เปรียบเทียบการเปลี่ยนแปลงได้ง่ายขึ้น เพราะลดความแตกต่างด้านการเว้นวรรคที่ไม่เกี่ยวข้อง

ใช้เครื่องมือจัดรูปแบบ SQL อย่างไร?

วางหรือป้อนคำสั่งลงในช่อง SQL แล้วส่งข้อมูลเพื่อรับฉบับที่จัดรูปแบบแล้วในช่อง Beautified SQL ระบบจะส่งข้อมูลที่ป้อนไปยังเซิร์ฟเวอร์ผ่าน HTTPS เพื่อประมวลผล และจะไม่จัดเก็บข้อมูลนั้น

1. คัดลอกคำสั่งให้ครบถ้วน รวมถึง common table expression ที่ต้องการเก็บไว้ จากนั้นตรวจสอบความคิดเห็นและเครื่องหมายอัฒภาคปิดท้ายในผลลัพธ์
2. ป้อนคำสั่งในช่อง SQL และหากทำได้ ควรหลีกเลี่ยงการจัดรูปแบบเฉพาะส่วนที่แยกออกมาจากคำสั่งเต็ม
3. อ่านผลลัพธ์ในช่อง Beautified SQL โดยใส่ใจเป็นพิเศษกับนิพจน์ที่ซ้อนกันและไวยากรณ์เฉพาะภาษาถิ่น
4. ทดลองรันคำสั่งที่จัดรูปแบบแล้วในสภาพแวดล้อมสำหรับการพัฒนาหรือ staging ที่เหมาะสมก่อนนำไปใช้งานจริง

หากทำงานกับฐานข้อมูลที่มีข้อมูลละเอียดอ่อน ให้ตรวจสอบนโยบายขององค์กรก่อนส่งข้อความคำสั่งค้นหาไปยังเครื่องมือที่ประมวลผลบนเซิร์ฟเวอร์ ลบรหัสผ่าน โทเค็นการเข้าถึง ข้อมูลส่วนบุคคล และค่าคงที่ที่เป็นความลับ หากข้อมูลเหล่านั้นไม่จำเป็นต่อการทำความเข้าใจคำสั่งค้นหา

ควรอ่าน SQL ที่จัดรูปแบบแล้วอย่างไร?

อ่านผลลัพธ์โดยไล่ตามระดับการเยื้องและขอบเขตของแต่ละส่วนคำสั่ง อย่าถือว่ารูปแบบใหม่เป็นหลักฐานว่าคำสั่งถูกต้อง เมื่อแต่ละส่วนเชิงตรรกะอยู่คนละบรรทัดหรือคนละระดับการเยื้อง โดยทั่วไปจะแยก SELECT, FROM, WHERE, GROUP BY และ ORDER BY ระดับบนสุดได้ง่ายขึ้น

• คำสั่งค้นหาย่อยที่เยื้องไว้ แสดงว่าผลลัพธ์ภายในถูกนำไปใช้ที่ตำแหน่งใดของคำสั่งภายนอก
• เงื่อนไขที่จัดแนวไว้ ช่วยให้ตรวจสอบลำดับการประมวลผลของ AND และ OR ได้ง่ายขึ้น แต่ตามค่าเริ่มต้น AND จะมีลำดับความสำคัญเหนือ OR และวงเล็บยังคงเป็นตัวกำหนดการจัดกลุ่มเชิงตรรกะ
• ส่วนคำสั่ง JOIN ที่แยกออกจากกัน ช่วยให้เห็นว่าเงื่อนไข ON แต่ละรายการเป็นของตารางใด
• รายการ SELECT ที่แยกเป็นส่วนชัดเจน ช่วยให้สังเกตเครื่องหมายจุลภาคที่หายไป คอลัมน์ซ้ำ และนามแฝงที่กำกวมได้ง่ายขึ้น
• แขนง CASE ที่มองเห็นชัดเจน ช่วยให้ผู้ตรวจสอบจับคู่คีย์เวิร์ด WHEN, THEN, ELSE และ END ได้

สตริงในอัญประกาศ ตัวเลข เครื่องหมายวรรคตอน และความคิดเห็นล้วนมีความหมายใน SQL จึงควรตรวจสอบองค์ประกอบเหล่านี้แทนที่จะคิดว่าเป็นเพียงส่วนของการจัดรูปแบบ อักขระที่มีเครื่องหมายกำกับเสียงหรืออักขระนอกชุดละตินอาจใช้ได้ในสตริงลิเทอรัลและตัวระบุที่อยู่ในอัญประกาศ ทั้งนี้ขึ้นอยู่กับฐานข้อมูลและการเข้ารหัสอักขระที่ใช้

ตัวอย่างการจัดรูปแบบสั้น ๆ

ลองดูข้อมูลเข้าขนาดกะทัดรัดนี้

Input: SELECT id,name FROM customers WHERE active=1 ORDER BY name;

ฉบับที่จัดรูปแบบให้อ่านง่ายอาจแสดงได้ดังนี้

Output: SELECT id, name

FROM customers

WHERE active = 1

ORDER BY name;

คำสั่งค้นหาที่มี join จะอ่านง่ายขึ้นอย่างชัดเจนเมื่อจัดระดับการเยื้อง

Input: SELECT o.id,c.name FROM orders o JOIN customers c ON c.id=o.customer_id WHERE o.total>100;

ผลลัพธ์ที่อ่านง่ายอาจแยก SELECT, FROM, JOIN, ON และ WHERE ไว้คนละบรรทัด พร้อมคงการเปรียบเทียบ o.total > 100 ไว้ การใช้ตัวพิมพ์ใหญ่หรือตัวพิมพ์เล็ก ระยะห่าง และตำแหน่งขึ้นบรรทัดอาจแตกต่างกันไปตามแนวทางการจัดรูปแบบ จึงควรมองตัวอย่างเหล่านี้เป็นเพียงรูปแบบการจัดวาง ไม่ใช่มาตรฐานตายตัวที่รับประกันว่าจะใช้เสมอ

การจัดรูปแบบช่วยหา SQL ที่ผิดได้ไหม?

ไม่ได้ การปรับ SQL ให้อ่านง่ายไม่เหมือนกับการตรวจสอบคำสั่งด้วยตัวแยกวิเคราะห์ของฐานข้อมูล ผลลัพธ์ที่เครื่องมือนี้ระบุไว้คือ SQL ที่จัดรูปแบบแล้ว จึงไม่ควรใช้แทนเครื่องมือตรวจสอบไวยากรณ์ ตรวจสอบสคีมา หรือวางแผนการประมวลผล

อย่างไรก็ตาม รูปแบบที่ชัดเจนขึ้นอาจช่วยให้พบข้อผิดพลาดที่น่าจะเกิดขึ้นระหว่างการตรวจสอบ ตัวอย่างที่พบบ่อย ได้แก่ เครื่องหมายจุลภาคหายไปจากรายการ SELECT, วงเล็บเปิดปิดไม่ครบ, สตริงในอัญประกาศไม่มีเครื่องหมายปิด, JOIN ที่ไม่มีเงื่อนไขตามต้องการ หรือการจัดกลุ่มนิพจน์ AND หรือ OR ไม่ถูกต้อง นอกจากนี้ยังอาจช่วยให้สังเกตคำสงวนที่ถูกใช้เป็นตัวระบุโดยไม่มีอัญประกาศได้ง่ายขึ้น

ปัญหาบางอย่างไม่สามารถยืนยันได้หากไม่มีฐานข้อมูลเป้าหมาย คำสั่งที่ PostgreSQL ยอมรับอาจต้องแก้ไขเมื่อนำไปใช้กับ Microsoft SQL Server, MySQL, Oracle Database หรือ SQLite ส่วนตารางที่ไม่มีอยู่ คอลัมน์ที่ไม่รู้จัก ชนิดข้อมูลที่เข้ากันไม่ได้ และข้อผิดพลาดด้านสิทธิ์ โดยทั่วไปต้องใช้กลไกฐานข้อมูลหรือเครื่องมือพัฒนาที่เข้าใจภาษาถิ่นนั้นในการวินิจฉัย

เมื่อไรที่ไม่จำเป็นต้องจัดรูปแบบ SQL?

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

การจัดรูปแบบอาจไม่ใช่ขั้นตอนที่เหมาะสมในกรณีต่อไปนี้:

• ไฟล์ migration ผ่านการลงลายมือชื่อ การทำ checksum หรือการเปรียบเทียบแบบไบต์ต่อไบต์ด้วยวิธีอื่น
• คำสั่งค้นหาแบบย่อหรือกะทัดรัดฝังอยู่ในสิ่งส่งมอบที่จำกัดขนาด และไม่มีใครต้องตรวจสอบคำสั่งนั้น
• งานเร่งด่วนคือการตรวจสอบความถูกต้อง วิเคราะห์แผนการประมวลผล หรือปรับประสิทธิภาพ ไม่ใช่การทำให้อ่านง่าย
• คำสั่งค้นหามีค่าที่เป็นความลับ ซึ่งนโยบายองค์กรไม่อนุญาตให้ส่งไปยังบริการที่ประมวลผลบนเซิร์ฟเวอร์

หากต้องจัดรูปแบบทั้ง repository ให้ทำซ้ำได้อย่างสม่ำเสมอ เครื่องมือจัดรูปแบบผ่านบรรทัดคำสั่งที่เข้าใจภาษาถิ่นอาจเหมาะกว่า เพราะสามารถ commit การตั้งค่าไว้พร้อมกับโค้ดได้ สำหรับเพย์โหลด API แบบมีโครงสร้างที่ภายในมี SQL ตัวตรวจสอบและจัดรูปแบบ JSON ช่วยตรวจสอบ JSON ที่ห่อหุ้มอยู่ได้ แต่ตัว SQL ยังคงต้องประมวลผลด้วยเครื่องมือเฉพาะสำหรับ SQL

คำถามที่พบบ่อย

จัดรูปแบบ SQL แล้วการทำงานของ NULL จะเปลี่ยนไหม?

ไม่เปลี่ยน การเว้นวรรคและการเยื้องไม่มีผลต่อตรรกะแบบสามค่าของ SQL หรือการทำงานของ NULL ถึงอย่างนั้น ควรตรวจสอบนิพจน์อย่าง column = NULL ซึ่งโดยทั่วไปต้องใช้ IS NULL เพราะเครื่องมือจัดรูปแบบจะไม่แก้ข้อผิดพลาดด้านความหมายนี้ให้

จัดรูปแบบ SQL หลายคำสั่งพร้อมกันได้ไหม?

ไม่มีเอกสารระบุว่ารองรับการจัดรูปแบบ SQL หลายคำสั่งพร้อมกัน ให้จัดรูปแบบทีละคำสั่ง

ใส่ความคิดเห็นไว้ในข้อมูลเข้าได้อย่างปลอดภัยไหม?

ความคิดเห็นอาจมีหมายเลขอ้างอิงตั๋ว ชื่อโฮสต์ภายในองค์กร รายละเอียดลูกค้า หรือบันทึกการปฏิบัติงาน แม้ SQL ที่ประมวลผลได้จะไม่มีค่าลิเทอรัลที่ละเอียดอ่อนก็ตาม ตรวจสอบทั้งความคิดเห็นแบบบรรทัดเดียวและแบบบล็อกก่อนส่งข้อความไปยังเซิร์ฟเวอร์

คีย์เวิร์ด SQL ควรใช้ตัวพิมพ์ใหญ่หรือตัวพิมพ์เล็ก?

โดยทั่วไปใช้ได้ทั้งสองแบบ เพราะกลไกฐานข้อมูลจำนวนมากไม่แยกตัวพิมพ์ใหญ่และตัวพิมพ์เล็กสำหรับคีย์เวิร์ดที่ไม่มีอัญประกาศ ให้ใช้แนวทางเดียวกับที่ repository กำหนด และระวังตัวระบุในอัญประกาศ เพราะฐานข้อมูลบางระบบจะเก็บรักษาหรือแยกความแตกต่างของตัวพิมพ์

ควรตรวจสอบอะไรก่อนรันคำสั่งที่จัดรูปแบบแล้ว?

ยืนยันภาษาถิ่นของฐานข้อมูลเป้าหมาย ตรวจสอบเงื่อนไข WHERE และ JOIN รวมทั้งตรวจสอบขอบเขตธุรกรรมของคำสั่ง UPDATE, DELETE และคำสั่งที่เปลี่ยนแปลงสคีมา ให้ทดลองรันคำสั่งที่มีความเสี่ยงในฐานข้อมูลสำหรับการพัฒนาหรือ staging ก่อน โดยควรใช้ข้อมูลที่ใกล้เคียงกับการใช้งานจริงและมีข้อมูลสำรองที่เหมาะสม