PRQL: Bahasa Kueri Relasional yang Dipipelinkan

 (github.com/PRQL)
4 poin oleh GN⁺ 2023-07-27 | 1 komentar | Bagikan ke WhatsApp
  • PRQL adalah bahasa modern untuk mentransformasi data, yang ditujukan sebagai bahasa pengganti SQL yang mudah dibaca, eksplisit, dan deklaratif seperti SQL
  • Kueri disusun sebagai pipeline logis di mana tahap transformasi meneruskan hasil sebelumnya, serta mendukung abstraksi seperti variabel dan fungsi
  • PRQL dikompilasi ke SQL agar dapat digunakan dengan semua basis data yang menggunakan SQL
  • Contoh bahasanya menggunakan transformasi seperti from, filter, derive, group, aggregate, sort, take, dan filter menggantikan peran WHERE dan HAVING di SQL
  • Fitur sintaks mencakup penulisan tanggal yang jelas, coalesce, variabel yang merujuk ke variabel lain, F-string mirip Python, S-string yang menggunakan SQL sebagai escape hatch, notasi pengurutan menurun, dan ekspresi rentang
  • Tersedia PRQL Playground untuk eksperimen di browser, PRQL Book sebagai dokumentasi bahasa, dan prql-lang.org yang menyediakan perbandingan SQL dan contoh
  • Per Juni 2026, PRQL dapat digunakan melalui integrasi yang didukung atau binding bahasa yang didukung, tetapi masih ada beberapa bug dan fitur yang belum tersedia, dan cakupan kesiapan penerapan untuk tim nonteknis masih terbatas pada kueri yang cukup sederhana
  • Fokus pengembangan adalah pengerjaan resolver baru, penyelesaian bug prioritas, menutup kesenjangan fitur yang tersisa agar bisa digunakan untuk sebagian besar kueri SQL standar, serta menambahkan dukungan eksperimental untuk modul dan proyek multi-berkas
  • Titik integrasi yang tersedia mencakup VS Code extension, Jupyter integration, QStudio integration, Jupyter magic, pyprql Docs, dan prqlc-js
  • Repositori terdiri dari kompiler prqlc yang ditulis dengan Rust dan area konten web web; prqlc mengompilasi PRQL ke SQL serta mencakup CLI dan berbagai binding bahasa

Bacaan terkait

1 komentar

 
GN⁺ 2023-07-27
Opini di Hacker News

  • Contoh di situs web https://prql-lang.org/ tampaknya menjadi keunggulan terbesar PRQL, terutama karena SQL yang dihasilkan rapi dan intuitif, bentuknya seperti sesuatu yang mungkin ditulis langsung oleh orang
    10–15 tahun lalu, orang membuat database baru seperti Mongo, Riak, Influx dan meyakinkan developer aplikasi untuk memakainya di proyek baru. Namun sekarang makin banyak pilihan konservatif yang lebih mudah diadopsi, seperti EdgeDB, TimescaleDB, dan PRQL, yaitu menaruh add-on atau query preprocessor di atas Postgres
    Skema dan migrasi di sisi Edge juga bagus, tetapi sintaks PRQL lebih intuitif. Karena dalam kode aplikasi sudah ada banyak pipeline transformasi data seperti chain map/filter di TypeScript, iterator Rust, enumerable Ruby, Java stream, .NET LINQ, dan Rx di berbagai bahasa, konsepnya terasa sangat akrab. Hal yang hebat adalah kita bisa menghasilkan SQL yang bagus dari PRQL, menyimpannya, memeriksanya nanti, melihat execution plan, dan menambahkan indeks di tempat yang diperlukan

    • Kelihatannya cukup bagus, tetapi tampak hanya berbeda sangat kecil dari SQL. Jika Ruby adalah “sintaks yang lebih ramah yang ditranspile ke Python”, rasanya orang akan memakai yang dipelajari lebih dulu dan tidak merasa perlu mempelajari yang lain
      Contohnya sengaja membuat SQL terlihat lebih bertele-tele. from employees / select {id, first_name, age} / sort age / take 10 memang tampak lebih baik daripada SELECT ... FROM ... ORDER BY ... LIMIT ... yang dipecah ke banyak baris, tetapi SQL sebenarnya juga bisa ditulis seperti select id, first_name, age from employees order by age limit 10; tanpa kurung kurawal, perbedaannya hanya sekitar order by vs sort, jadi nyaris cuma selisih satu-dua karakter
    • Saya kurang paham. Contoh-contohnya terlihat jauh lebih sulit dibaca daripada SQL, dan saya tidak tahu kenapa harus memakai ini
      Kemampuan mengubah urutan bagian query memang sesuatu yang sering dikeluhkan semua orang soal SQL, tetapi sebagai gantinya ada berbagai jenis tanda kurung, titik dua, dan sintaks lain yang masuk tanpa alasan jelas, dan tampaknya tidak melakukan sesuatu yang memang belum bisa dilakukan SQL. Saya penasaran apa daya tariknya

  • Baru-baru ini kami menggabungkan dukungan PRQL ke ClickHouse: https://github.com/ClickHouse/ClickHouse/pull/50686
    Saat ini masih lebih bersifat eksperimental, dan belum jelas apakah benar-benar layak dipakai atau berguna. Ada juga sedikit kekhawatiran terkait Rust: https://github.com/ClickHouse/ClickHouse/issues/52053#issuecomment-1643805521

    • Keren. Kalau begitu, apakah itu berarti juga bisa dipakai di clickhouse-local?

  • Saya berharap PRQL tumbuh besar dan menjadi bahasa dengan dukungan kelas satu di Postgres. Aljabar relasional itu indah, tetapi SQL adalah rancangan awal yang berantakan dan seharusnya sudah diganti puluhan tahun lalu
    Bahkan Codd pun tidak puas dengan SQL. Hal yang ia temukan memang luar biasa, tetapi sejak itu kita sudah belajar banyak tentang desain bahasa pemrograman

    • Orang sering mengaitkan aljabar relasional dan SQL kemungkinan karena keduanya dipelajari bersama. Namun SQL sangat buruk sebagai bahasa relasional, dan di banyak tempat menyimpang dari gagasan inti bahwa relasi adalah himpunan tanpa urutan, misalnya dengan ORDER BY
      Masalah ini muncul ketika dibungkus sebagai subquery lalu pengurutan relasinya hilang, yang cukup tidak terduga. Model data PRQL sangat mirip dengan model relasional, dan perbedaan besarnya adalah relasi didefinisikan sebagai array tuple sehingga memiliki urutan. Saya berharap PRQL dikenal sebagai “bahasa relasional Mk II”
    • Tidak persis sama dengan yang diinginkan, tetapi DuckDB memiliki ekstensi PRQL [1] sekaligus ekstensi Postgres [2], jadi sepertinya di sana kita bisa meng-query database Postgres dengan PRQL
      Ada juga plugin DBeaver [3], meski dokumentasi dan penyederhanaan usability masih diperlukan, tetapi dengan itu pun mungkin bisa meng-query Postgres menggunakan PRQL. Terakhir, dengan pyprql [4], kita bisa meng-query Postgres dari 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
      Sebagai catatan, saya kontributor PRQL
    • Aljabar relasional tetap luar biasa. Yang membuat ide indah itu menjadi berantakan sampai sulit dipercaya adalah SQL
    • Saya pertama kali belajar SQL saat remaja 20 tahun lalu, dan masih ingat waktu itu saya merasa bahasanya aneh dan secara harfiah terasa terbalik
      Saat itu saya mengira saya hanya belum cukup tahu untuk memahami kenapa harus begitu, tetapi sekarang saya tahu tidak ada alasan untuk itu. SQL sudah menjadi seperti bahasa alami, sehingga meski tidak masuk akal, kita tidak bisa membantahnya dan harus mengucapkannya begitu saja. Namun SQL bukan bahasa alami, dan kita bisa membuat yang lebih baik
    • Saya selalu tidak suka cara memilih apa yang ingin diambil terlebih dahulu, baru kemudian memilih sumbernya. Bentuk sintaks di sini jauh lebih intuitif

  • Jika keluhan utama terhadap SQL adalah urutan SELECT, FROM, WHERE tidak bisa diubah, maka untuk bahasa yang dirancang pada tahun 70-an, itu sebenarnya cukup baik
    Sebaliknya, PRQL terlihat punya banyak noise arbitrer dalam sintaksnya. Saya tidak tahu mengapa join side:left p=positions (p.id==employees.employee_id) harus lebih disukai daripada LEFT JOIN positions AS p ON p.id = employees.employee_id

    • Masalah inti SQL adalah kita terjebak dalam cara penulisan yang sangat kaku, dan itu tidak cocok dengan alur berpikir saya
      Cara seperti PRQL, di mana dari atas ke bawah setiap tahap menjadi transformasi dari tahap sebelumnya, jauh lebih masuk akal. SQL membutuhkan manual referensi, sedangkan PRQL terasa seperti menuliskan langsung apa yang ingin dilakukan kueri. Namun sintaks join PRQL sangat buruk; seharusnya tetap mempertahankan kata kunci eksplisit seperti left join, dan alias serta singkatan kolom join juga bisa dibuat lebih baik
    • Keluhan nyata terhadap SQL ada dua, dan sisanya cukup baik
      Pertama, di dalam select yang sama, kolom yang dipilih sebelumnya tidak bisa digunakan di bagian setelahnya. Setelah gnarly_calculation AS some_value, kita tidak bisa menulis some_value * 2 AS some_value_doubled, melainkan harus membungkusnya dengan subkueri. Kedua, tidak bisa menentukan semua kolom kecuali kolom tertentu. Saat perlu membawa perhitungan sementara dari subkueri tetapi tidak membutuhkannya di output akhir, kita tidak bisa mengatakan sesuatu seperti * EXCEPT some_value, melainkan harus mencantumkan semua kolom output yang diinginkan
    • Mungkin karena terbiasa dengan R dan paradigma tidyverse, secara umum paradigma dan sintaks ini terlihat cukup mudah dibaca
      Contoh yang dipilih mungkin kasus di mana tanda kurung dan koma sangat membantu, tetapi dalam konteks bahasa secara keseluruhan itu tidak terlalu buruk. : dipakai secara konsisten seperti argumen bernama, dan = tampaknya dipakai untuk alias
    • Karena sekarang jenis join menjadi argumen dari operasi join, dan kata pertama dalam kalimat adalah join, jadi lebih jelas operasi sebenarnya apa
      Sebagai contoh pemanggilan fungsi umum pun, foo(bar) lebih baik daripada “bar to foo()”
    • Masalah SQL sama seperti masalah deklarasi variabel ala C. Jika kodenya dibaca keras-keras, ia tampak sedikit lebih baik daripada alternatifnya, tetapi dalam praktiknya menimbulkan masalah pada keterbacaan dan parsing/pemrosesan

  • PRQL 0.9 baru saja dirilis beberapa jam lalu, jadi waktunya pas. Catatan rilis bisa dilihat di sini: https://github.com/PRQL/prql/releases/tag/0.9.0
    Ada perubahan yang memutus kompatibilitas cukup besar, yaitu sintaks tuple berubah dari [] menjadi {}. Awalnya hal-hal ini terlihat seperti list, tetapi seiring waktu disadari bahwa sebenarnya itu adalah tuple. Seperti disebutkan di catatan rilis, dengan mengosongkan [], dukungan array bisa segera mulai ditambahkan. Sebagai catatan, saya adalah kontributor PRQL

  • Keterbatasan PRQL adalah, secara desain, ia hanya mendukung SELECT. Untuk menyisipkan/mengubah/menghapus data, harus kembali ke SQL
    Data scientist di tim bisa memberikan kueri dalam PRQL, tetapi untuk memasukkannya ke pipeline data nyata, kueri itu harus diterjemahkan ke SQL. Akan bagus jika setidaknya ada dukungan fitur terbatas seperti menyisipkan ke tabel sementara baru. Misalnya bentuk seperti from tracks / filter artist == "Bob Marley" / save bob_marley_tmp

    • Saya tidak melihat alasan mengapa PRQL tidak bisa mendukung perubahan data. Cukup sediakan operator insert/update/delete yang harus berada di akhir pipeline, dan menerima nama tabel sebagai argumen
      SQL seperti UPDATE counters SET value = value + 1 WHERE name LIKE 'prefix.%' mungkin bisa ditulis di PRQL sebagai from counters / filter startswith(name, 'prefix.') / derive { new_value = value + 1 } / select { name, new_value } / update counters
    • Benar, di titik ini saya kehilangan minat

  • Tulisan yang tidak boleh absen di sini: “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

    • Saya sangat menyukai tulisan ini, dan situs web PRQL juga menautkannya
      Tujuan PRQL adalah menjadi bahasa yang bagus untuk diintegrasikan dan dibangun di atasnya. Kami tidak ingin membuat N bahasa untuk N database. PRQL akan selalu open source dan tidak akan membuat produk komersial, jadi menurut saya ini jauh lebih mungkin terwujud dibanding bahasa khusus per database atau per produk. Saya pengembang PRQL
    • Sanggahan terbaik: https://www.scattered-thoughts.net/writing/against-sql/

  • Show HN sebelumnya: https://news.ycombinator.com/item?id=31897430
    “Show HN: PRQL 0.2 – a better SQL” diposting oleh maximilianroos pada 27 Juni 2022, mendapat 378 poin dan 161 komentar
    Posting asli saat pertama kali diusulkan: https://news.ycombinator.com/item?id=30060784
    “PRQL – A proposal for a better SQL” diposting oleh maximilianroos pada 24 Januari 2022, mendapat 650 poin dan 295 komentar

  • Mengingatkan saya pada KQL dari Microsoft: https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/

    • KQL sangat bagus, sampai-sampai saya merindukannya setiap kali memakai SQL
    • Itu satu-satunya kesenangan yang saya rasakan saat memakai Azure

  • Sintaks tidak terlalu penting; yang penting adalah apa yang dilakukan oleh optimizer
    Banyak masalah SQL saat ini terlihat seperti beban lama. Karena engine lama tidak menangani sintaks modern dengan baik, banyak orang terlatih menulis query yang sulit dibaca, rumit, dan bersarang dalam. Misalnya, common table expression (CTE) dulu langsung dimaterialisasi, sehingga gaya lama seperti SELECT FROM (SELECT FROM (SELECT FROM A JOIN (SELECT ) B ON A.x=B.x))) merajalela
    Berkat perbaikan pada cara engine menangani CTE, semakin mudah menulis query yang dapat dipahami dan dapat dikomposisikan seperti WITH A AS (...), WITH B AS (...), WITH C AS (SELECT y FROM A) SELECT result FROM C WHERE .... Dengan tambahan fitur seperti window function modern, SELECT * EXCEPT, dan TOP X FOLLOWING yang lebih kompleks, SQL bisa menjadi lebih sederhana
    Dalam lingkungan seperti ini, saya tidak melihat perbaikan kecil berupa bentuk sintaks lain seperti PRQL memberi manfaat besar. Memang bisa ditulis ulang sebagai pipeline yang terlihat imperatif, tetapi optimizer mungkin membuang sebagian darinya. Memang ada hal-hal yang perlu diperbaiki di SQL, tetapi saya belum melihat alasan yang meyakinkan untuk perbedaan yang bersifat tampilan atau sintaksis