PRQL: ภาษาคิวรีเชิงสัมพันธ์แบบไปป์ไลน์

 (github.com/PRQL)
4 คะแนน โดย GN⁺ 2023-07-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • PRQL เป็นภาษาสมัยใหม่สำหรับการแปลงข้อมูล โดยมุ่งเป็น ภาษาแทน SQL ที่อ่านง่าย ชัดเจน และประกาศเจตนาได้เหมือน SQL
  • คิวรีประกอบด้วย ไปป์ไลน์เชิงตรรกะ ที่แต่ละขั้นของการแปลงจะรับผลลัพธ์จากขั้นก่อนหน้า และรองรับ abstraction อย่างตัวแปรและฟังก์ชัน
  • PRQL จะ คอมไพล์เป็น SQL เพื่อให้ใช้งานร่วมกับฐานข้อมูลทุกตัวที่ใช้ SQL ได้
  • ตัวอย่างภาษานี้ใช้การแปลงอย่าง from, filter, derive, group, aggregate, sort, take โดย filter ทำหน้าที่แทน WHERE และ HAVING ของ SQL
  • ความสามารถด้านไวยากรณ์มีทั้งการเขียนวันที่ที่ชัดเจน, coalesce, ตัวแปรที่อ้างอิงตัวแปรอื่น, F-string คล้าย Python, S-string ที่ใช้ SQL เป็น escape hatch, การเขียนลำดับแบบเรียงจากมากไปน้อย และ range expression
  • มี PRQL Playground สำหรับทดลองบนเบราว์เซอร์, PRQL Book ซึ่งเป็นเอกสารภาษา และ prql-lang.org ที่มีการเปรียบเทียบกับ SQL และตัวอย่างต่างๆ
  • ณ เดือนมิถุนายน 2026 สามารถใช้งานผ่านการเชื่อมต่อที่รองรับหรือ language binding ที่รองรับได้ แต่ยังคงมีบั๊กและฟีเจอร์ที่ขาดหายไปบางส่วน และขอบเขตความพร้อมสำหรับการนำไปใช้กับทีมที่ไม่ใช่สายเทคนิคยังจำกัดอยู่ที่คิวรีที่ค่อนข้างเรียบง่าย
  • โฟกัสการพัฒนาคือการทำงานกับ resolver ใหม่, แก้บั๊กที่มีลำดับความสำคัญสูง, ปิดช่องว่างของฟีเจอร์ที่เหลือเพื่อให้ใช้ได้กับคิวรี SQL มาตรฐานส่วนใหญ่ และเพิ่มการรองรับแบบทดลองสำหรับโมดูลและโปรเจกต์หลายไฟล์
  • จุดเชื่อมต่อที่มีให้ได้แก่ VS Code extension, Jupyter integration, QStudio integration, Jupyter magic, pyprql Docs, prqlc-js
  • ที่เก็บโค้ดประกอบด้วยคอมไพเลอร์ prqlc ที่เขียนด้วย Rust และส่วนเว็บคอนเทนต์ web โดย prqlc ทำหน้าที่คอมไพล์ PRQL เป็น SQL และมีทั้ง CLI กับ language binding หลายภาษา

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

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

 
GN⁺ 2023-07-27
ความคิดเห็นจาก Hacker News

  • ตัวอย่างบนเว็บไซต์ https://prql-lang.org/ ดูเหมือนจะเป็นจุดแข็งที่สุดของ PRQL โดยเฉพาะ SQL ที่สร้างออกมานั้นสะอาดและอ่านเข้าใจง่าย ราวกับเป็นรูปแบบที่คนเขียนเองได้
    เมื่อ 10–15 ปีก่อน เราสร้างฐานข้อมูลใหม่อย่าง Mongo, Riak, Influx แล้วพยายามโน้มน้าวนักพัฒนาแอปให้นำไปใช้ในโปรเจกต์ใหม่ แต่ทุกวันนี้มีทางเลือกแบบอนุรักษ์นิยมที่นำ แอดออนหรือ query preprocessor มาวางบน Postgres มากขึ้น เช่น EdgeDB, TimescaleDB, PRQL ทำให้เริ่มใช้งานได้ง่ายกว่ามาก
    สคีมาและการ migrate ของฝั่ง Edge ก็ดี แต่ไวยากรณ์ของ PRQL อ่านเป็นธรรมชาติกว่า ในโค้ดแอปพลิเคชันมี data transformation pipeline อยู่แล้วมากมาย เช่น chain ของ map/filter ใน TypeScript, iterator ของ Rust, enumerable ของ Ruby, stream ของ Java, .NET LINQ และ Rx ในหลายภาษา แนวคิดนี้จึงคุ้นเคยมาก จุดที่ยอดเยี่ยมคือสามารถให้ PRQL สร้าง SQL ที่ดีออกมา บันทึกไว้ ตรวจสอบภายหลัง ดู execution plan และเพิ่ม index ในจุดที่จำเป็นได้

    • ดูค่อนข้างดี แต่เหมือนต่างจาก SQL เพียงเล็กน้อยมาก ถ้า Ruby เป็น “ไวยากรณ์ที่เป็นมิตรกว่าซึ่ง transpile เป็น Python” ก็คงรู้สึกว่าใครเรียนอะไรก่อนก็ใช้สิ่งนั้นไป และไม่จำเป็นต้องเรียนอีกอัน
      ตัวอย่างทำให้ SQL ดูเยิ่นเย้อเกินจริงโดยตั้งใจ from employees / select {id, first_name, age} / sort age / take 10 ดูดีกว่า SELECT ... FROM ... ORDER BY ... LIMIT ... ที่แยกหลายบรรทัด แต่ SQL จริงก็เขียนได้เป็น select id, first_name, age from employees order by age limit 10 เช่นกัน และแค่ไม่มีปีกกา แต่ต่างกันประมาณ order by กับ sort จึงแทบเป็นแค่ ต่างกันหนึ่งสองตัวอักษร
    • ยังไม่ค่อยเข้าใจ ตัวอย่างดูอ่านยากกว่า SQL มาก และไม่รู้ว่าทำไมต้องใช้สิ่งนี้
      การสลับลำดับส่วนต่าง ๆ ของ query ได้เป็นเรื่องที่ทุกคนบ่นเกี่ยวกับ SQL ก็จริง แต่แลกมาด้วยวงเล็บหลายชนิด โคลอน และไวยากรณ์อื่น ๆ ที่ดูใส่เข้ามาโดยไม่มีเหตุผล อีกทั้งก็ไม่ได้ทำอะไรที่ SQL ทำไม่ได้อยู่แล้วเป็นพิเศษ เลยสงสัยว่า จุดดึงดูด คืออะไร

  • เพิ่ง merge การรองรับ PRQL เข้า ClickHouse: https://github.com/ClickHouse/ClickHouse/pull/50686
    ตอนนี้ยังใกล้เคียงกับการทดลอง และยังไม่แน่ใจว่าจะใช้งานได้จริงหรือมีประโยชน์แค่ไหน มีความกังวลเกี่ยวกับ Rust อยู่เล็กน้อยด้วย: https://github.com/ClickHouse/ClickHouse/issues/52053#issuecomment-1643805521

    • เจ๋งมาก ถ้าอย่างนั้นแปลว่าจะใช้ใน clickhouse-local ได้ด้วยหรือเปล่า อยากรู้

  • หวังว่า PRQL จะเติบโตอย่างมากจนกลายเป็น ภาษาที่รองรับระดับ first-class ใน Postgres พีชคณิตเชิงสัมพันธ์นั้นงดงาม แต่ SQL เป็นงานออกแบบรุ่นแรกที่กระท่อนกระแท่น ซึ่งควรถูกแทนที่ตั้งแต่หลายสิบปีก่อนแล้ว
    แม้แต่ Codd เองก็ไม่พอใจกับ SQL สิ่งที่เขาคิดค้นนั้นน่าทึ่ง แต่หลังจากนั้นเราได้เรียนรู้เรื่องการออกแบบภาษาโปรแกรมมาอีกมาก

    • เหตุผลที่ผู้คนมักโยงพีชคณิตเชิงสัมพันธ์กับ SQL เข้าด้วยกัน อาจเป็นเพราะเรียนทั้งสองอย่างมาพร้อมกัน แต่ SQL เป็นภาษาสำหรับ relational ที่แย่มาก และขัดกับหลักสำคัญหลายจุด เช่น ความคิดหลักที่ว่า relation เป็นเซตที่ไม่มีลำดับ กลับถูกทำลายด้วย ORDER BY
      ปัญหานี้ปรากฏให้เห็นในลักษณะที่เมื่อห่อด้วย subquery แล้วการเรียงลำดับของ relation จะหายไป ซึ่งค่อนข้างเหนือความคาดหมาย data model ของ PRQL คล้ายกับ relational model มาก และความต่างใหญ่คือ relation ถูกนิยามเป็น อาร์เรย์ของ tuple จึงมีลำดับ หวังว่า PRQL จะเป็นที่รู้จักในฐานะ “ภาษาเชิงสัมพันธ์ Mk II”
    • อาจไม่ตรงกับสิ่งที่ต้องการเป๊ะ ๆ แต่ DuckDB มีทั้งส่วนขยาย PRQL [1] และส่วนขยาย Postgres [2] ดังนั้นน่าจะสามารถ query ฐานข้อมูล Postgres ด้วย PRQL ผ่านที่นั่นได้
      ยังมีปลั๊กอิน DBeaver [3] ด้วย ซึ่งยังต้องปรับปรุงเอกสารและทำให้การใช้งานเรียบง่ายขึ้น แต่ก็น่าจะใช้ query Postgres ด้วย PRQL ได้เช่นกัน สุดท้าย ถ้าใช้ pyprql [4] ก็สามารถ query Postgres จาก Jupyter notebook ได้
      [1]: https://github.com/ywelsch/duckdb-prql
      [2]: https://duckdb.org/docs/extensions/postgres_scanner.html
      [3]: https://github.com/PRQL/prql/issues/1643
      [4]: https://github.com/PRQL/pyprql
      อนึ่ง ผมเป็นผู้ร่วมพัฒนา PRQL
    • พีชคณิตเชิงสัมพันธ์ยังคงยอดเยี่ยม สิ่งที่ทำให้แนวคิดอันงดงามนั้นเละเทะอย่างไม่น่าเชื่อคือ SQL
    • ตอนเป็นวัยรุ่นเมื่อ 20 ปีก่อน ผมเรียน SQL เป็นครั้งแรก และยังจำได้ว่าตอนนั้นคิดว่าภาษานี้แปลกและให้ความรู้สึกว่า กลับหัวกลับหาง อย่างแท้จริง
      ตอนนั้นคิดว่าเป็นเพราะยังรู้น้อยเกินไปที่จะเข้าใจว่าทำไมต้องเป็นแบบนั้น แต่ตอนนี้รู้แล้วว่าไม่มีเหตุผลอะไรเลย SQL กลายเป็นเหมือนภาษาธรรมชาติ ต่อให้ไม่สมเหตุสมผลก็โต้แย้งไม่ได้ ต้องพูดไปตามนั้น แต่ SQL ไม่ใช่ภาษาธรรมชาติ และเราทำให้ดีกว่านี้ได้
    • ผมไม่เคยชอบวิธีที่ต้องเลือกก่อนว่าจะดึงอะไร แล้วค่อยเลือก source ทีหลัง รูปแบบไวยากรณ์ที่นี่ เป็นธรรมชาติกว่า มาก

  • หากข้อร้องเรียนหลักต่อ SQL คือการที่ไม่สามารถสลับลำดับ SELECT, FROM, WHERE ได้ ก็ถือว่าค่อนข้างดีทีเดียวสำหรับภาษาที่ออกแบบในยุค 70
    ในทางกลับกัน PRQL ดูเหมือนมีสัญญาณรบกวนตามอำเภอใจในไวยากรณ์อยู่มาก ไม่เข้าใจว่าทำไมเราควรชอบ join side:left p=positions (p.id==employees.employee_id) มากกว่า LEFT JOIN positions AS p ON p.id = employees.employee_id

    • ปัญหาหลักของ SQL คือมันถูกขังอยู่ในรูปแบบการเขียนที่เข้มงวดมาก และไม่ค่อยเข้ากับลำดับความคิดของผม
      วิธีที่แต่ละขั้นจากบนลงล่างเป็น การแปลง ของขั้นก่อนหน้าแบบ PRQL นั้นสมเหตุสมผลกว่ามาก SQL ต้องพึ่งคู่มืออ้างอิง แต่ PRQL ให้ความรู้สึกเหมือนเขียนสิ่งที่อยากให้คิวรีทำลงไปตรง ๆ อย่างไรก็ตาม ไวยากรณ์ join ของ PRQL แย่มาก และควรรักษาคีย์เวิร์ดแบบ left join ที่ชัดเจนไว้ อีกทั้งควรทำการย่อ alias และคอลัมน์ join ให้ดีกว่านี้ได้
    • ข้อร้องเรียนจริง ๆ ต่อ SQL มีสองอย่าง ส่วนที่เหลือค่อนข้างดี
      อย่างแรก ไม่สามารถใช้คอลัมน์ที่เลือกไว้ก่อนหน้าใน select เดียวกันในภายหลังได้ เช่น หลังจาก gnarly_calculation AS some_value แล้วจะเขียน some_value * 2 AS some_value_doubled ไม่ได้ ต้องห่อด้วย subquery อย่างที่สอง ไม่สามารถระบุ คอลัมน์ทั้งหมด ยกเว้นบางคอลัมน์ ได้ เวลาต้องดึงค่าคำนวณกลางจาก subquery ขึ้นมาแต่ไม่ต้องการให้อยู่ในผลลัพธ์สุดท้าย ก็ไม่สามารถพูดแบบ * EXCEPT some_value ได้ ต้องไล่ระบุคอลัมน์ผลลัพธ์ที่ต้องการทั้งหมด
    • อาจเพราะคุ้นกับ R และพาราดาม tidyverse โดยรวมแล้วพาราดามและไวยากรณ์นี้ดูอ่านง่ายทีเดียว
      ตัวอย่างที่เลือกมาอาจเป็นกรณีที่วงเล็บกับจุลภาคช่วยได้มาก แต่ในบริบทของภาษาทั้งหมดก็ไม่ได้แย่ขนาดนั้น : ถูกใช้สม่ำเสมอเหมือน อาร์กิวเมนต์แบบคีย์เวิร์ด ส่วน = ดูเหมือนใช้กับ alias
    • เพราะตอนนี้ชนิดของ join กลายเป็นอาร์กิวเมนต์ของตัวดำเนินการ join และคำแรกของประโยคคือ join ทำให้ชัดเจนขึ้นว่าการดำเนินการจริงคืออะไร
      แม้แต่ตัวอย่างการเรียกฟังก์ชันทั่วไป foo(bar) ก็ยังดีกว่า “bar to foo()”
    • ปัญหาของ SQL เหมือนกับปัญหาการประกาศตัวแปรสไตล์ C ถ้าอ่านโค้ดออกเสียงอาจดูดีกว่าทางเลือกเล็กน้อย แต่ในความเป็นจริงมันก่อปัญหาเรื่อง ความอ่านง่ายและการพาร์ส/ประมวลผล

  • PRQL 0.9 เพิ่งปล่อยออกมาเมื่อไม่กี่ชั่วโมงก่อน จังหวะเหมาะพอดี ดู release notes ได้ที่นี่: https://github.com/PRQL/prql/releases/tag/0.9.0
    มี breaking change ค่อนข้างใหญ่คือไวยากรณ์ tuple เปลี่ยนจาก [] เป็น {} ตอนแรกสิ่งเหล่านี้ดูเหมือน list แต่เมื่อเวลาผ่านไปก็รู้ว่าจริง ๆ แล้วมันคือ tuple ตาม release notes หากปล่อย [] ให้โล่งไว้ ก็จะเริ่มรองรับ array ได้ในเร็ว ๆ นี้ อนึ่ง ผมเป็นผู้มีส่วนร่วมกับ PRQL

  • ข้อจำกัดของ PRQL คือโดยการออกแบบแล้วรองรับเฉพาะ SELECT เท่านั้น หากต้องการ insert/modify/delete ข้อมูล ก็ต้องกลับไปใช้ SQL
    นักวิทยาศาสตร์ข้อมูลในทีมอาจส่งคิวรีเป็น PRQL ได้ แต่ถ้าจะใส่เข้าไปใน data pipeline จริง ก็ต้องแปลเป็น SQL อย่างน้อยถ้ารองรับฟีเจอร์แบบจำกัด เช่น insert ลงตารางชั่วคราวใหม่ได้ก็คงดี เช่นรูปแบบ from tracks / filter artist == "Bob Marley" / save bob_marley_tmp

    • ดูเหมือนไม่มีเหตุผลที่ PRQL จะรองรับการเปลี่ยนแปลงข้อมูลไม่ได้ แค่วางตัวดำเนินการ insert/update/delete ที่ต้องมาอยู่ท้าย pipeline และให้รับชื่อตารางเป็นอาร์กิวเมนต์ก็พอ
      SQL อย่าง UPDATE counters SET value = value + 1 WHERE name LIKE 'prefix.%' น่าจะเขียนใน PRQL ได้แบบ from counters / filter startswith(name, 'prefix.') / derive { new_value = value + 1 } / select { name, new_value } / update counters
    • ใช่ ตรงนี้แหละที่ผมหมดความสนใจ

  • บทความที่ขาดไม่ได้ตรงนี้: “I don't want to learn your garbage query language” [1]
    [1] https://erikbern.com/2018/08/30/i-dont-want-to-learn-your-garbage-query-language.html

    • ผมชอบบทความนี้มาก และเว็บไซต์ PRQL ก็ลิงก์ถึงด้วย
      เป้าหมายของ PRQL คือการเป็น ภาษาที่ยอดเยี่ยม สำหรับรวมเป็นหนึ่งเดียวและสร้างต่อยอดบนมัน ไม่อยากสร้างภาษา N ภาษาให้กับฐานข้อมูล N ตัว PRQL จะเป็นโอเพนซอร์สเสมอและจะไม่ทำผลิตภัณฑ์เชิงพาณิชย์ ดังนั้นผมมองว่ามันเป็นไปได้จริงกว่าภาษาที่ผูกกับแต่ละฐานข้อมูลหรือแต่ละผลิตภัณฑ์มาก ผมเป็นนักพัฒนา PRQL
    • ข้อโต้แย้งที่ดีที่สุด: https://www.scattered-thoughts.net/writing/against-sql/

  • Show HN ก่อนหน้า: https://news.ycombinator.com/item?id=31897430
    “Show HN: PRQL 0.2 – a better SQL” โพสต์โดย maximilianroos เมื่อ 27 มิถุนายน 2022 ได้ 378 คะแนน มี 161 ความเห็น
    โพสต์ต้นฉบับที่เสนอครั้งแรก: https://news.ycombinator.com/item?id=30060784
    “PRQL – A proposal for a better SQL” โพสต์โดย maximilianroos เมื่อ 24 มกราคม 2022 ได้ 650 คะแนน มี 295 ความเห็น

  • นึกถึง KQL ของ Microsoft: https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/

    • KQL ยอดเยี่ยมมาก จนคิดถึงมันทุกครั้งที่ต้องใช้ SQL
    • เป็นความสุขเพียงอย่างเดียวที่รู้สึกได้เวลาใช้ Azure

  • ไวยากรณ์ไม่ได้สำคัญมากนัก สิ่งที่สำคัญคือ ตัวเพิ่มประสิทธิภาพ ทำอะไร
    ตอนนี้ปัญหาจำนวนมากของ SQL ดูเหมือนเป็นภาระตกค้างจากอดีต เอนจินรุ่นเก่าเคยจัดการไวยากรณ์สมัยใหม่ได้ไม่ดี ทำให้ผู้คนจำนวนมากถูกฝึกให้เขียนคิวรีที่อ่านยาก ซับซ้อน และซ้อนกันลึกมาก ตัวอย่างเช่น นิพจน์ตารางร่วม (CTE) มักถูก materialize ทันที จึงเต็มไปด้วยสไตล์เก่า ๆ อย่าง SELECT FROM (SELECT FROM (SELECT FROM A JOIN (SELECT ) B ON A.x=B.x)))
    ด้วยการปรับปรุงการจัดการ CTE ของเอนจิน ทำให้การเขียนคิวรีที่เข้าใจได้และประกอบร่วมกันได้อย่าง WITH A AS (...), WITH B AS (...), WITH C AS (SELECT y FROM A) SELECT result FROM C WHERE ... ทำได้ง่ายขึ้นเรื่อย ๆ เมื่อมีฟีเจอร์อย่าง window functions สมัยใหม่, SELECT * EXCEPT และความสามารถที่ซับซ้อนขึ้นอย่าง TOP X FOLLOWING เพิ่มเข้ามา SQL ก็สามารถเรียบง่ายขึ้นได้
    ในสภาพแวดล้อมแบบนี้ ผมไม่คิดว่าการปรับปรุงเล็ก ๆ ในรูปแบบไวยากรณ์อื่นอย่าง PRQL จะให้ประโยชน์มากนัก อาจเขียนใหม่เป็น pipeline ที่ดูเหมือน imperative ได้ก็จริง แต่ optimizer ก็อาจทิ้งบางส่วนของมันไปได้ เป็นความจริงที่ SQL ยังมีสิ่งที่ควรทำให้ดีกว่านี้ แต่ผมยังไม่เห็นเหตุผลที่น่าเชื่อถือสำหรับความแตกต่างด้านรูปลักษณ์หรือไวยากรณ์