BigQuery ตอนนี้รองรับไวยากรณ์ SQL แบบ Pipe แล้ว

 (cloud.google.com)
13 คะแนน โดย GN⁺ 2025-02-18 | 3 ความคิดเห็น | แชร์ทาง WhatsApp

Pipe Query Syntax คืออะไร?

  • เป็นไวยากรณ์ขยายของ GoogleSQL ที่ช่วยให้เขียนคิวรีในโครงสร้างเชิงเส้นซึ่งอ่านง่ายและดูแลรักษาได้สะดวก
  • รองรับการทำงานแบบเดียวกับ GoogleSQL เดิม (Standard SQL) เช่น การเลือกข้อมูล การจัดกลุ่ม การ join การกรอง เป็นต้น
  • สามารถกำหนดลำดับการทำงานได้อย่างอิสระ และเขียนคิวรีที่ซับซ้อนได้โดยไม่ต้องใช้ nested subquery

Standard SQL vs Pipe Query Syntax

  • Standard SQL
    • ต้องทำตามลำดับไวยากรณ์ที่กำหนดไว้
    • หากใช้การ aggregate หลายชั้น จำเป็นต้องใช้ CTE (Common Table Expression) หรือ nested subquery
    • ต้องเขียนคอลัมน์ซ้ำใน SELECT, GROUP BY, ORDER BY
  • Pipe Query Syntax
    • สามารถใช้ตัวดำเนินการ Pipe ได้ในลำดับใดก็ได้
    • ทำ aggregate หลายชั้นได้ง่ายเพียงเพิ่มตัวดำเนินการ Pipe
    • ประกาศคอลัมน์เพียงครั้งเดียวก็พอ

โครงสร้างพื้นฐานของ Pipe Query Syntax

    1. เริ่มต้นด้วย clause FROM
    1. เพิ่มการทำงานต่อจาก |> (ตัวดำเนินการ pipe)
    1. เชื่อม |> หลายตัวเข้าด้วยกันเพื่อประกอบคิวรีเป็นลำดับขั้น
      (เช่น สามารถสลับลำดับระหว่างการกรอง → การ aggregate → การ join ได้)
  • คุณสมบัติหลัก
    • เพิ่มตัวดำเนินการ Pipe ให้กับคิวรีใดก็ได้ → ขยายคิวรี GoogleSQL เดิมได้ด้วยการเติมตัวดำเนินการ |> ต่อท้าย
    • ลำดับการทำงานยืดหยุ่น → ใช้ตัวดำเนินการได้ตามลำดับและจำนวนครั้งที่ต้องการ
    • ใช้ได้ในทุกสภาพแวดล้อมที่รองรับ GoogleSQL → ใช้ได้กับคิวรี, view, table-valued function เป็นต้น
    • ใช้ร่วมกับไวยากรณ์ SQL เดิมได้ → subquery ใช้ Standard SQL ส่วนคิวรีหลักใช้ไวยากรณ์ Pipe ได้
    • อ้างอิง alias ทั้งหมดที่นิยามไว้ในขั้นก่อนหน้าได้
    • เริ่มด้วย clause FROM ได้ → แล้วค่อยเพิ่มตัวดำเนินการ |> เพื่อขยายคิวรีแบบค่อยเป็นค่อยไป

ความแตกต่างระหว่าง Pipe Query Syntax กับ Standard SQL

  • เริ่มคิวรีด้วย clause FROM ได้
  • ตัวดำเนินการ pipe SELECT จะไม่ทำ aggregate โดยต้องใช้ตัวดำเนินการ pipe AGGREGATE แยกต่างหาก
  • ใช้ตัวดำเนินการ pipe WHERE สำหรับการกรอง ซึ่งรวมความสามารถของ WHERE, HAVING, QUALIFY ใน Standard SQL ไว้ด้วยกัน สามารถกรองได้ในทุกขั้นตอน → ทำให้เขียนคิวรีได้ยืดหยุ่นมากขึ้น

ข้อดีของ Pipe Query Syntax

  • เขียนคิวรีตามลำดับตรรกะได้ → ช่วยให้อ่านคิวรีได้ง่ายขึ้น
  • ดูแลรักษาง่าย → ทำงานซับซ้อนได้โดยไม่ต้องใช้ nested subquery
  • ลำดับการทำงานยืดหยุ่น → ใช้การทำงานในลำดับที่ต้องการได้
  • การกรองเข้าใจง่ายขึ้น → ใช้ WHERE เพื่อกรองข้อมูลในหลายขั้นตอนได้
  • เขียนคิวรี aggregate ที่ซับซ้อนได้ง่ายขึ้น → ใช้ตัวดำเนินการ AGGREGATE เพื่อทำ aggregate อย่างชัดเจน

รองรับในสถานะ Pre-GA และยังมีข้อจำกัดด้านการรองรับอยู่

บทความที่เกี่ยวข้อง

3 ความคิดเห็น

 
carnoxen 2025-02-18

https://github.com/tc39/proposal-pipeline-operator

เป็นโอเปอเรเตอร์ที่คุ้นหน้าคุ้นตาพอสมควรเลยนะ
 
halfenif 2025-02-18

พอดู prql มาก่อน แล้วมาเห็นไวยากรณ์แบบไปป์ไลน์ของ Google ก็รู้สึกว่ามันดูรก ๆ นิดหน่อยนะ
 
GN⁺ 2025-02-18
ความคิดเห็นใน Hacker News

  • ไวยากรณ์แบบ pipe ของ SQL ถูกนำไปใช้งานใน Databricks ตั้งแต่วันที่ 30 มกราคม 2025

    • ก่อนหน้านี้การขยาย SQL ทำได้ยาก และ table-valued function ก็ซับซ้อน
    • ตอนนี้สามารถใช้ higher-order function เพื่อเสริมข้อมูล การพยากรณ์ การจัดกลุ่ม เป็นต้น ได้แล้ว
    • ตัวอย่างเช่น สามารถกรองคำสั่งซื้อหลังจากวันที่กำหนด จากนั้นสรุปยอดใช้จ่ายรวมตามลูกค้า แล้วกรองลูกค้าที่มียอดถึงเกณฑ์ ก่อนจะ join กับข้อมูลลูกค้าได้
    • SQL แบบทำซ้ำโดยใช้ pipe อาจทำงานร่วมกับ GenAI ได้ดีกว่า

  • PRQL เป็นแนวคิดคล้ายกันที่คอมไพล์ไปเป็น SQL

    • ตัวอย่างเช่น สามารถกรองข้อมูลใบแจ้งหนี้ คำนวณค่าธรรมเนียม แล้วกรองข้อมูลที่มีรายได้เกินจำนวนที่กำหนดได้

  • หากมีการขยายไวยากรณ์ SQL ต่อไปเรื่อย ๆ ความซับซ้อนก็อาจเพิ่มขึ้น

    • อยากให้ผู้พัฒนา SQL มุ่งเน้นเรื่อง source map เป็นต้น เพื่อให้รองรับไวยากรณ์ทางเลือกจากภายนอกได้ดีขึ้น
    • แต่ละโปรเจ็กต์หรือแต่ละคนก็จะสามารถเลือกใช้รูปแบบไวยากรณ์ SQL ที่เหมาะกับตัวเองได้

  • ตอนที่ไวยากรณ์แบบ pipe ถูกประกาศครั้งแรก ทีม SQLite ได้ลองทดสอบมัน

    • พบว่าอักขระ pipe ไม่ได้จำเป็นเสมอไป และไวยากรณ์ก็ยังทำงานได้แม้ pipe จะเป็นตัวเลือก
    • ส่วนตัวคิดว่าวิธีนี้ดูดีกว่า

  • PRQL เป็นไวยากรณ์แบบเน้น pipe สำหรับ SQL DB แต่เพราะเป็นภาษาใหม่ จึงไม่รองรับ backward compatibility กับ SQL

    • แม้จะไม่ได้รับการสนับสนุนจากบริษัทยักษ์ใหญ่อย่าง Google แต่ไวยากรณ์สะอาดกว่า

  • ใช้ได้ใน DuckDB เช่นกัน

  • การพิมพ์ ">" หลัง pipe อาจน่ารำคาญได้

  • ภาษา Malloy ไม่ได้เป็นไวยากรณ์แบบ pipe แต่มีไวยากรณ์เชิงวิเคราะห์ที่คล้ายกัน

    • พัฒนาโดย Lloyd Tabb ผู้ร่วมก่อตั้ง Looker

  • หลังจากใช้ Kusto Query Language ก็หวังว่า SQL จะมีความสามารถลักษณะนี้

    • ถ้ามี DB มากพอรองรับเป็นส่วนขยาย ก็น่าจะมีความเป็นไปได้