ปัญหาของ SQL และแนวทางแก้ไข: ไวยากรณ์แบบ Pipe ของ SQL

 (research.google)
13 คะแนน โดย GN⁺ 2024-08-26 | 11 ความคิดเห็น | แชร์ทาง WhatsApp
  • SQL เป็นภาษาพื้นฐานสำหรับการประมวลผลข้อมูลเชิงโครงสร้างมานาน 50 ปี แต่เรียนรู้ยาก ใช้งานลำบาก และขยายต่อได้ยาก
  • ปัญหาของ SQL แบบเดิม: การบังคับลำดับไวยากรณ์, ไวยากรณ์ที่ซ้ำซ้อน, ความจำเป็นในการใช้ซับคิวรี, การไหลของข้อมูลแบบ 'จากด้านในออกด้านนอก' และข้อจำกัดด้านการขยายความสามารถ เป็นต้น
  • ใน GoogleSQL มีการเลือกใช้แนวทางขยาย SQL เพื่อแก้ปัญหาของ SQL
    • นำไวยากรณ์การไหลของข้อมูลแบบโครงสร้าง Pipe เข้ามาใช้ใน SQL เพื่อแก้ปัญหาของ SQL แบบเดิม
    • ทำให้สามารถเรียนรู้และใช้งาน SQL ได้ยืดหยุ่นยิ่งขึ้น โดยยังคงระบบนิเวศเดิมไว้ และรักษาความเข้ากันได้กับ SQL เดิมอย่างสมบูรณ์
      • นำโอเปอเรเตอร์ SQL เดิมกลับมาใช้ซ้ำและประกอบด้วย Pipe ได้ในลำดับตามต้องการ
      • โอเปอเรเตอร์แต่ละตัวใน Pipe มองเห็นได้เฉพาะตารางอินพุต จึงมีขอบเขตที่ชัดเจน
      • ยังคงรักษาความหมายเชิงประกาศไว้
      • สามารถจับคู่แบบหนึ่งต่อหนึ่งกับ relational algebra ได้
      • ปรับปรุงความสามารถในการขยายด้วย table-valued function
    • ตัวอย่างเช่น สามารถเขียนการ aggregate หลายขั้นต่อเนื่องกันได้โดยไม่ต้องใช้ซับคิวรี
    • SQL ที่ใช้ไวยากรณ์แบบ Pipe เรียนรู้ง่ายและใช้งานง่ายกว่า และมีความยืดหยุ่นดีขึ้นมากเพราะสามารถนำโอเปอเรเตอร์หลากหลายชนิดมาใช้ในลำดับใดก็ได้
    • โอเปอเรเตอร์แบบ Pipe ทำงานตามลำดับ ทำให้ผู้ใช้สามารถกรอง สรุปผล และจัดเรียงข้อมูลได้ง่ายขึ้น
  • ประสบการณ์การใช้งานใน GoogleSQL
    • ได้รับการยอมรับจากผู้ใช้อย่างต่อเนื่องและมีฟีดแบ็กเชิงบวก
    • คิวรีที่ซับซ้อนก็สามารถแสดงแบบเชิงเส้นได้
    • เอื้อต่อการแก้ไขและดีบัก
    • การรองรับจากเครื่องมือ IDE ดีขึ้น
    • เป็นประโยชน์ต่อเครื่องมือสร้างและแปลงโค้ด SQL
    • มีข้อได้เปรียบที่อาจเป็นไปได้สำหรับการประยุกต์ใช้ AI
  • การนำไปใช้และแผนในอนาคต
    • ใน GoogleSQL มีการติดตั้งไวยากรณ์แบบ Pipe เป็นคอมโพเนนต์ที่ใช้ร่วมกัน
    • เอนจินคิวรีเดิมสามารถเปิดใช้ไวยากรณ์แบบ Pipe ได้ค่อนข้างง่าย
    • กำลังพิจารณาการรองรับภายนอกใน BigQuery และ Spanner
    • มีคุณค่าพอที่จะผลักดันให้ถูกรวมไว้ในมาตรฐาน SQL ในอนาคต

ความเห็นของ GN⁺

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

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

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

 
dkang 2024-08-26

เครื่องหมายแคเร็ตบน pipe ฟังดูเป็นชุดค่าผสมที่เหมือนจะทำให้มือขวาปวดเลยนะ 🤣
ตอนนี้ SQL ก็คงต้องมีอะไรให้ปรับปรุงจริง ๆ นั่นแหละ
แต่ปัญหาคือผ่านมาตั้ง 30-40 ปีแล้วก็ยังหาวิธีปรับปรุงไม่ได้..
 
savvykang 2024-08-26

ดูเหมือนว่าระบบนิเวศสำหรับไวยากรณ์เพิ่มเติมของ SQL น่าจะต้องให้ Google เป็นผู้นำ แต่สุดท้ายแล้วฝ่ายธุรกิจจะเดินหน้าสิ่งนี้ต่อเนื่องจริงหรือเปล่า?
 
chusine 2024-08-26

ก็คือ dplyr นั่นแหละ 5555
 
koreaisbest 2024-08-26

ทำไมพอเป็นสิ่งที่ Google ทำแล้วถึงรู้สึกเหมือนมันจะพังทุกทีนะ..
Gemini ก็ตอบเหมือนเด็กเกรียนจนไม่อยากใช้เลย
 
ilotoki0804 2024-08-26

ดูเหมือนว่าจะคล้ายกับแนวทางที่ ORM ใช้กันนะ
 
winterjung 2024-08-26

แค่ดูตัวอย่างด้านล่างในเปเปอร์ก็น่าจะชัดแล้วว่า Google SQL อ่านง่ายกว่าจริง ๆ

standard sql

SELECT c_count, COUNT(*) AS custdist  
FROM  
    ( SELECT c_custkey, COUNT(o_orderkey) c_count  
      FROM customer  
      LEFT OUTER JOIN orders ON c_custkey = o_custkey  
           AND o_comment NOT LIKE '%unusual%packages%'  
      GROUP BY c_custkey  
    ) AS c_orders  
GROUP BY c_count  
ORDER BY custdist DESC, c_count DESC;

google sql

FROM customer  
|> LEFT OUTER JOIN orders ON c_custkey = o_custkey  
      AND o_comment NOT LIKE '%unusual%packages%'  
|> AGGREGATE COUNT(o_orderkey) c_count  
   GROUP BY c_custkey  
|> AGGREGATE COUNT(*) AS custdist  
   GROUP BY c_count  
|> ORDER BY custdist DESC, c_count DESC;
 
mwma91 2024-08-30

ทำให้นึกถึง LINQ ของ C# เลยครับ ทุกครั้งที่ใช้ SQL ผมมักคิดเสมอว่าคงจะดีถ้าลำดับของ SELECT เปลี่ยนไปอยู่หลัง FROM, WHERE....
ตอนแรกอาจจะยังไม่คุ้นเลยรู้สึกแปลก ๆ แต่พอค่อย ๆ อ่านไปจะรู้สึกว่าลำดับการไหลของเนื้อหาธรรมชาติกว่ามากครับ
 
regentag 2024-08-27

ฝั่ง SQL ดูเหมือนจะอ่านง่ายกว่านะครับ
 
leftliber 2024-08-27

สำหรับผม ฝั่ง SQL อ่านง่ายกว่ามากเลยครับ 555 คนที่เริ่มต้นมาจาก SQL ก็น่าจะเป็นแบบนั้นกันเป็นส่วนใหญ่นะ...
 
superwoou 2024-08-28

ผมก็รู้สึกว่าอะไรที่คุ้นเคยอ่านง่ายกว่านะครับ.. 555
 
GN⁺ 2024-08-26
ความคิดเห็นจาก Hacker News
  • ไวยากรณ์แบบ pipe ของ SQL อ่านง่ายขึ้น
  • ตอนเขียน SQL query ที่ Google ไวยากรณ์แบบ pipe มีประโยชน์
  • หวังว่าไวยากรณ์แบบ pipe ของ SQL จะแพร่หลายมากขึ้น
  • ผลลัพธ์จากการลองแปลง PDF เป็น HTML ใน Google AI Studio ออกมาดี
  • ใช้ SQL มานานกว่า 20 ปีแล้ว แต่ก็ยังมีปัญหาในการเขียนบาง query ให้ออกมาในรูปแบบที่ต้องการ
  • โครงการโอเพนซอร์ส ZetaSQL ของ Google ได้เพิ่มเอกสารเกี่ยวกับไวยากรณ์แบบ pipe
  • ความไม่พอใจต่อไวยากรณ์ของ SQL เป็นเรื่องที่มีลำดับความสำคัญต่ำ
    • ต้องการฟีเจอร์อย่าง algebraic data types, ตรรกะบูลีนที่แท้จริง, และการประกอบแบบฟังก์ชัน
  • มีความพยายามมากมายที่จะลดความยากในการเขียน SQL แต่ยังไม่ประสบความสำเร็จ
    • แนวทางของผู้เขียนค่อยเป็นค่อยไปและเหมาะกับผู้ใช้ SQL เดิม
  • ไวยากรณ์แบบ pipeline ดีกว่าสถานะปัจจุบัน
    • ไวยากรณ์ที่จำลองการรัน query เป็นกราฟทิศทางของงานน่าจะดีกว่า
      • สามารถจำลอง join เป็นงาน "cross-reference" ที่ใช้ data stream ตั้งแต่สองชุดขึ้นไปและสร้าง data stream หนึ่งชุด
      • CTE สามารถจำลองเป็นสิ่งที่สร้าง data stream หลายชุดได้
      • recursive CTE สามารถจำลองเป็นวงจรใน execution graph ได้
  • คล้ายกับ Elixir
    • ถ้ายังรองรับไวยากรณ์ SQL แบบเดิมก็ถือว่าใช้ได้ แต่ query ที่มี JOIN หลายตัว, subquery และ aggregation อาจอ่านยาก
  • ชวนให้นึกถึง PRQL และ SPL ของ Splunk