ตัวจัดรูปแบบ SQL

ใช้ ตัวจัดรูปแบบ SQL ใน Ali Hub DevTools พร้อมการตรวจสอบ ผลลัพธ์ ข้อมูลความเป็นส่วนตัว และข้อจำกัดที่ระบุไว้อย่างชัดเจน

ข้อมูลหลัก

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

ติดตั้งเครื่องมือนี้

เพิ่มเครื่องมือนี้ลงในอุปกรณ์เพื่อเข้าถึงได้อย่างรวดเร็ว

ตัวจัดรูปแบบ SQL

จัด SQL ให้อ่านง่ายโดยรักษา keyword expression join string ความคิดเห็น และโครงสร้าง query ไว้

Make SQL queries easier to review

SQL query ยาวในบรรทัดเดียวตรวจ join filter column และ expression ซ้อนได้ยาก เครื่องมือนี้จัดเป็น layout ที่อ่านง่าย

การจัดรูปแบบไม่ยืนยันความปลอดภัย ประสิทธิภาพ สิทธิ์ หรือความเข้ากันได้ของ database version ต้องเก็บต้นฉบับและ diff

ใช้ query ที่มี alias join predicate aggregate หรือ comment เมื่อต้องการ และอย่ารัน statement ที่ยังไม่ review ใน production

Formatting is not SQL validation

SQL แสดง statement identifier literal operator clause join subquery และ comment การจัดรูปแบบทำให้ความสัมพันธ์เห็นชัด

Formatter จัด whitespace แต่ไม่ตรวจสิทธิ์ ตาราง schema transaction query plan หรือความหมายทางธุรกิจ

SQL dialect แตกต่างกัน keyword quote function และ extension ต้องทดสอบด้วยเครื่องมือ database เป้าหมาย

How to format SQL

  1. ใส่ query ครบหรือ statement ที่รองรับ
  2. ตรวจ SELECT list alias join เงื่อนไข grouping ordering subquery และ comment
  3. เปรียบเทียบ string identifier placeholder operator และลำดับ clause กับ source
  4. ก่อน execute ใช้ parser linter explain plan ตรวจสิทธิ์ และ tests ที่ต้องใช้
  5. ลบ credential ข้อมูลส่วนบุคคล และ schema ลับจากตัวอย่าง

Formatting method

  • อ่าน token keyword

    อ่าน token keyword clause expression literal comment และส่วนที่ซ้อนจาก SQL

  • เพิ่มบรรทัดและการเยื้องให้ SELECT JOIN

    เพิ่มบรรทัดและการเยื้องให้ SELECT JOIN predicate และ subquery ตรวจง่าย

  • รักษา string identifier

    รักษา string identifier placeholder operator comment และลำดับตาม source

การรองรับ dialect การกู้ parser การจัดการ comment quote identifier และข้อความ error ที่แน่นอนต้องตรวจด้วย engine จริง

Read the formatted result

ผลสำเร็จคือ SQL ที่จัดให้อ่านง่าย ตรวจ column literal alias join เงื่อนไข comment และลำดับ clause ให้ตรง source

ผลล้มเหลวไม่ได้พิสูจน์ dialect หรือ recovery เฉพาะ ต้องมีหลักฐาน runtime

หากรันไม่ได้หรือช้า ให้ตรวจ syntax สิทธิ์ schema plan index และ data แยกกัน

ข้อผิดพลาดที่พบบ่อย

การมองการเยื้องเป็น safety หรือ performance review อาจซ่อน filter กว้างหรือ join ผิด

การเปลี่ยน literal identifier placeholder หรือ comment อาจเปลี่ยนพฤติกรรมแอป

อย่าคิดว่า database ทุกชนิดใช้ dialect เดียวกัน

อย่าใส่ SQL production หรือ credential ในตัวอย่าง

ข้อจำกัดและกรณีพิเศษ

ความสามารถนี้คือการจัดแสดง SQL ไม่รับรอง syntax permission schema performance transaction หรือผลการ execute

vendor dialect procedural SQL quoted identifier comment และ query ใหญ่ต้องทดสอบกับเครื่องมือเป้าหมาย

อย่าใส่ SQL ลับหากนโยบายไม่อนุญาต

Examples

การจัดรูปแบบตรวจ SQL หรือไม่

การจัดรูปแบบตรวจ SQL หรือไม่

ใส่ query ครบหรือ statement ที่รองรับ

ผลสำเร็จคือ SQL ที่จัดให้อ่านง่าย ตรวจ column literal alias join เงื่อนไข comment และลำดับ clause ให้ตรง source

ผล query จะเปลี่ยนไหม

ผล query จะเปลี่ยนไหม

ตรวจ SELECT list alias join เงื่อนไข grouping ordering subquery และ comment

ผลล้มเหลวไม่ได้พิสูจน์ dialect หรือ recovery เฉพาะ ต้องมีหลักฐาน runtime

string literal ถูกเก็บไหม

string literal ถูกเก็บไหม

เปรียบเทียบ string identifier placeholder operator และลำดับ clause กับ source

หากรันไม่ได้หรือช้า ให้ตรวจ syntax สิทธิ์ schema plan index และ data แยกกัน

รองรับ SQL dialect ทุกแบบไหม

รองรับ SQL dialect ทุกแบบไหม

ก่อน execute ใช้ parser linter explain plan ตรวจสิทธิ์ และ tests ที่ต้องใช้

ผลสำเร็จคือ SQL ที่จัดให้อ่านง่าย ตรวจ column literal alias join เงื่อนไข comment และลำดับ clause ให้ตรง source

ช่วยเพิ่ม performance ไหม

ช่วยเพิ่ม performance ไหม

ลบ credential ข้อมูลส่วนบุคคล และ schema ลับจากตัวอย่าง

ผลล้มเหลวไม่ได้พิสูจน์ dialect หรือ recovery เฉพาะ ต้องมีหลักฐาน runtime

comment ถูกเก็บไหม

comment ถูกเก็บไหม

ใส่ query ครบหรือ statement ที่รองรับ

หากรันไม่ได้หรือช้า ให้ตรวจ syntax สิทธิ์ schema plan index และ data แยกกัน

Frequently asked questions

การจัดรูปแบบตรวจ SQL หรือไม่

ไม่ ใช้ parser linter client database และ tests ของ dialect เป้าหมาย

ผล query จะเปลี่ยนไหม

สำหรับ input ที่รองรับควรเปลี่ยนเฉพาะ layout แต่ต้องเทียบและทดสอบผล

string literal ถูกเก็บไหม

ตัวอย่างเก็บ literal ไว้ ตรวจ diff เมื่อ space หรือ escape สำคัญ

รองรับ SQL dialect ทุกแบบไหม

อย่าสันนิษฐาน ยืนยัน syntax ของ vendor กับเครื่องมือเป้าหมาย

ช่วยเพิ่ม performance ไหม

ไม่ ใช้ explain plan index statistics และวิธี tuning ของ database

comment ถูกเก็บไหม

ตัวอย่างเก็บ comment ไว้ ควรตรวจ input จริง

SQL อันตรายจะปลอดภัยไหม

ไม่ มันไม่ทำ parameterize เปลี่ยนสิทธิ์ หรือลบ statement อันตราย

หลังจัดรูปแบบควรทำอะไร

ตรวจ diff รัน dialect checks และ tests ตรวจสิทธิ์และ plan แล้ว execute ผ่าน workflow ที่ควบคุม

References