PRQL: Boru hatlı ilişkisel sorgu dili

 (github.com/PRQL)
4 puan yazan GN⁺ 2023-07-27 | 1 yorum | WhatsApp'ta paylaş
  • PRQL, veriyi dönüştürmeye yönelik modern bir dil olup SQL gibi okunabilir, açık ve bildirime dayalı bir SQL alternatifi olmayı hedefler
  • Sorgular, dönüşüm adımlarının önceki sonucu devraldığı mantıksal bir boru hattı olarak yapılandırılır ve değişkenler ile fonksiyonlar gibi soyutlamaları destekler
  • SQL kullanan tüm veritabanlarıyla birlikte kullanılabilmesi için PRQL SQL'e derlenir
  • Dil örnekleri from, filter, derive, group, aggregate, sort, take gibi dönüşümleri kullanır; filter, SQL'deki WHERE ve HAVING rollerinin yerini alır
  • Söz dizimi özellikleri arasında açık tarih gösterimi, coalesce, başka değişkenlere başvuran değişkenler, Python'a benzer F-string, SQL'i escape hatch olarak kullanan S-string, azalan sıralama gösterimi ve aralık ifadeleri bulunur
  • Tarayıcıda deneme için PRQL Playground, dil dokümantasyonu olan PRQL Book ve SQL karşılaştırmaları ile örnekler sunan prql-lang.org sağlanır
  • Haziran 2026 itibarıyla, desteklenen entegrasyonlar veya desteklenen dil binding'leri üzerinden kullanılabilir; ancak bazı hatalar ve eksik özellikler hâlâ vardır ve teknik olmayan ekiplere dağıtım için hazır kapsam oldukça basit sorgularla sınırlıdır
  • Geliştirme odağı; yeni resolver çalışması, öncelikli hataların çözülmesi, standart SQL sorgularının çoğunda kullanılabilmesi için kalan özellik açıklarının kapatılması ve modüller ile çok dosyalı projeler için deneysel desteğin eklenmesidir
  • Entegrasyon noktaları olarak VS Code extension, Jupyter integration, QStudio integration, Jupyter magic, pyprql Docs, prqlc-js sunulur
  • Depo, Rust ile yazılmış prqlc derleyicisi ve web içerik alanı webden oluşur; prqlc, PRQL'i SQL'e derler ve CLI ile çeşitli dil binding'lerini içerir

İlgili okumalar

1 yorum

 
GN⁺ 2023-07-27
Hacker News yorumları

  • Web sitesindeki https://prql-lang.org/ örnekler PRQL’in en büyük avantajı gibi görünüyor; özellikle üretilen SQL temiz ve sezgisel, insanın doğrudan yazmış olabileceği türden.
    10–15 yıl önce Mongo, Riak, Influx gibi yeni veritabanları yapıp uygulama geliştiricilerini yeni projelerde bunları kullanmaya ikna etmeye çalışırdık; bugün ise EdgeDB, TimescaleDB, PRQL gibi Postgres’in üzerine eklenti veya sorgu ön işleyicisi koyan daha muhafazakâr seçenekler arttı ve benimsemeleri çok daha kolay.
    Edge tarafındaki şema ve migration’lar da iyi, ama PRQL sözdizimi daha sezgisel. TypeScript’in map/filter zincirleri, Rust iterator’ları, Ruby enumerable’ları, Java stream’leri, .NET LINQ, çeşitli dillerdeki Rx gibi uygulama kodlarında zaten çok sayıda veri dönüştürme pipeline’ı olduğu için kavram oldukça tanıdık. PRQL’den iyi SQL üretip saklayabilmek, sonra kontrol edebilmek, yürütme planına bakabilmek ve gereken yerlere indeks ekleyebilmek harika.

    • Oldukça iyi görünüyor, ama SQL’den yalnızca çok küçük ayrıntılarla farklı gibi. Ruby “Python’a transpile edilen daha dostça bir sözdizimi” olsaydı, insan önce hangisini öğrendiyse onu kullanır, diğerini öğrenmeye pek gerek duymazdı gibi geliyor.
      Örnekler SQL’i keyfî olarak daha uzun görünür hâle getiriyor. Çok satıra bölünmüş SELECT ... FROM ... ORDER BY ... LIMIT ... yerine from employees / select {id, first_name, age} / sort age / take 10 daha iyi görünüyor, ama gerçek SQL de select id, first_name, age from employees order by age limit 10 diye yazılabilir; süslü parantez olmaması karşılığında order by ile sort farkı kadar, yani bir iki karakterlik fark gibi.
    • Pek anlayamıyorum. Örnekler SQL’den çok daha az okunabilir görünüyor ve bunu neden kullanmam gerektiğini bilmiyorum.
      Sorgu bölümlerinin sırasını değiştirebilmek herkesin SQL hakkında şikâyet ettiği bir nokta, ama bunun yerine farklı türde parantezler, iki noktalar ve başka sözdizimi öğeleri nedensizce giriyor; SQL’in zaten yapamadığı bir şeyi özellikle başardığı da görünmüyor. Cazibe noktası nedir, merak ediyorum.

  • Yakın zamanda ClickHouse’a PRQL desteğini merge ettik: https://github.com/ClickHouse/ClickHouse/pull/50686
    Şimdilik daha çok deneysel sayılır; gerçekten kullanılabilir ya da faydalı olup olmayacağı kesin değil. Rust ile ilgili bazı endişeler de var: https://github.com/ClickHouse/ClickHouse/issues/52053#issuecomment-1643805521

    • Harika. Öyleyse bu clickhouse-local içinde de kullanılabileceği anlamına mı geliyor, merak ediyorum.

  • PRQL’in büyük ölçüde büyüyüp Postgres’te birinci sınıf desteklenen bir dil olmasını isterim. İlişkisel cebir güzel, ama SQL onlarca yıl önce değiştirilmesi gereken sakar bir ilk tasarımdı.
    Codd bile SQL’den memnun değildi. Onun icat ettiği şey şaşırtıcı, ama o zamandan beri programlama dili tasarımı hakkında çok şey öğrendik.

    • İnsanların ilişkisel cebir ile SQL’i sık sık birlikte anmasının nedeni muhtemelen ikisini birlikte öğrenmiş olmaları. Ama SQL ilişkisel bir dil olarak çok kötü; ilişkilerin sırasız kümeler olduğu temel fikrini ORDER BY ile bozması gibi birçok yerde modele ters düşüyor.
      Bu sorun, alt sorguyla sardığınızda ilişkinin sıralamasının kaybolması gibi şekillerde ortaya çıkıyor ki bu epey beklenmedik. PRQL’in veri modeli ilişkisel modele çok benziyor; büyük fark, ilişkilerin tuple dizileri olarak tanımlanması ve bu yüzden sıralı olması. PRQL’in “ilişkisel dil Mk II” olarak bilinmesini umuyorum.
    • Tam istediğiniz şey değil, ama DuckDB’de hem PRQL eklentisi [1] hem de Postgres eklentisi [2] var; dolayısıyla orada Postgres veritabanını PRQL ile sorgulamak mümkün gibi görünüyor.
      Bir DBeaver eklentisi [3] de var; daha fazla dokümantasyon ve kullanım kolaylaştırması gerekiyor ama bununla da Postgres’i PRQL ile sorgulamak mümkün olabilir. Son olarak pyprql [4] kullanırsanız Jupyter notebook içinden Postgres’i sorgulayabilirsiniz.
      [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
      Not: PRQL katkıcısıyım.
    • İlişkisel cebir hâlâ müthiş. O güzel fikri inanılması güç ölçüde karmakarışık hâle getiren şey SQL.
    • 20 yıl önce, ergenken SQL’i ilk öğrendiğimde de dilin tuhaf ve kelimenin tam anlamıyla tersine dönmüş gibi olduğunu düşündüğümü hatırlıyorum.
      O zaman bunun neden böyle olması gerektiğini anlayacak kadar bilmediğimi sanmıştım; artık böyle bir nedeni olmadığını biliyorum. SQL doğal dil gibi olup çıktı: mantıksız olsa da itiraz edemiyorsunuz, sadece öyle konuşmanız gerekiyor. Ama SQL doğal dil değil ve daha iyisi yapılabilir.
    • Neyi sorgulayacağınızı seçtikten sonra kaynağı seçme biçimi hiç hoşuma gitmemişti. Buradaki sözdizimi biçimi çok daha sezgisel.

  • SQL hakkındaki başlıca şikâyet SELECT, FROM, WHERE sırasının değiştirilememesiyse, 70’lerde tasarlanmış bir dil için oldukça iyi sayılır.
    Buna karşılık PRQL’in söz diziminde epey keyfî gürültü var gibi görünüyor. join side:left p=positions (p.id==employees.employee_id) yazımını neden LEFT JOIN positions AS p ON p.id = employees.employee_id yerine tercih etmem gerektiğini bilmiyorum.

    • SQL’in temel sorunu, çok katı bir yazım biçimine hapsolmuş olması ve bunun benim düşündüğüm akışla pek uyuşmaması.
      PRQL’de olduğu gibi, yukarıdan aşağıya her adımın bir önceki adımın dönüşümü olması çok daha mantıklı. SQL’de referans kılavuzuna ihtiyaç duyuluyor; PRQL ise sorgunun yapmasını istediğiniz şeyi olduğu gibi yazıyormuşsunuz hissi veriyor. Yine de PRQL’in join söz dizimi çok kötü; açık left join türü anahtar sözcükleri korumalıydı, takma adlar ve join sütunu kısaltmaları da daha iyi tasarlanabilirdi.
    • SQL hakkındaki gerçek şikâyetlerim iki taneydi; geri kalanı oldukça iyiydi.
      Birincisi, aynı select içinde daha önce seçilen bir sütunu daha sonra kullanamıyorsunuz. gnarly_calculation AS some_value sonrasında some_value * 2 AS some_value_doubled gibi yazamıyor, alt sorguyla sarmalamanız gerekiyor. İkincisi, belirli sütunlar hariç tüm sütunları belirtemiyorsunuz. Ara hesaplamaları alt sorgudan yukarı taşımak gerekiyor ama nihai çıktıda gerekmiyorsa, * EXCEPT some_value gibi söyleyemiyor; istediğiniz tüm çıktı sütunlarını tek tek listelemek zorunda kalıyorsunuz.
    • R ve tidyverse paradigmasına alışkın olduğumdan olabilir; genel olarak bu paradigma ve söz dizimi epey okunabilir görünüyor.
      Seçilen örnek, parantezlerin ve virgüllerin çok işe yaradığı bir durum olabilir; ama dilin genel bağlamında o kadar kötü değil. : tutarlı biçimde anahtar sözcük argümanı gibi kullanılıyor, = ise takma adlar için kullanılıyor gibi.
    • Çünkü join türü artık join işleminin bir argümanı oluyor ve cümlenin ilk kelimesi join olduğu için asıl işlemin ne olduğu daha belirgin hale geliyor.
      Genel bir fonksiyon çağrısı örneğinde de foo(bar), “bar to foo()”dan daha iyidir.
    • SQL’in sorunu, C tarzı değişken bildirimi sorunuyla aynı. Kodu sesli okuduğunuzda alternatifinden biraz daha iyi görünüyor ama pratikte okunabilirlik ve ayrıştırma/işleme sorunlarına yol açıyor.

  • PRQL 0.9 birkaç saat önce yayımlandı; zamanlama iyi. Sürüm notlarını burada görebilirsiniz: https://github.com/PRQL/prql/releases/tag/0.9.0
    Tuple söz diziminin []’den {}’ye değiştiği, oldukça büyük bir geriye uyumsuz değişiklik var. Başta bunlar liste gibi görünüyordu; fakat zamanla aslında tuple olduklarını fark ettik. Sürüm notlarında belirtildiği gibi, []’yi boşta bırakırsak yakında dizi desteğini başlatabiliriz. Not: PRQL katkıcısıyım.

  • PRQL’in sınırı, tasarım gereği yalnızca SELECT desteklemesi. Veri eklemek/değiştirmek/silmek için tekrar SQL’e dönmeniz gerekiyor.
    Takımdaki veri bilimci PRQL ile sorgu verebilir; ama bunu gerçek veri pipeline’ına koymak için SQL’e çevirmek gerekir. En azından yeni bir geçici tabloya ekleme gibi sınırlı bir işlevi desteklese iyi olurdu. Örneğin from tracks / filter artist == "Bob Marley" / save bob_marley_tmp gibi.

    • PRQL’in veri değişikliklerini destekleyememesi için bir neden görmüyorum. Pipeline’ın sonuna gelmesi gereken insert/update/delete operatörleri koyup, tablo adını argüman olarak almalarını sağlamak yeterli.
      UPDATE counters SET value = value + 1 WHERE name LIKE 'prefix.%' gibi bir SQL, PRQL’de from counters / filter startswith(name, 'prefix.') / derive { new_value = value + 1 } / select { name, new_value } / update counters şeklinde yazılabilir.
    • Doğru, burada ilgimi kaybettim.

  • Burada eksik kalmaması gereken yazı: “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

    • Bu yazıyı çok seviyorum ve PRQL web sitesinde de bağlantı veriyoruz.
      PRQL’in hedefi, entegre edilmesi ve üzerine bir şeyler inşa edilmesi kolay harika bir dil olmak. N tane veritabanı için N tane dil yapmak istemiyoruz. PRQL her zaman açık kaynak olacak ve ticari bir ürün geliştirmeyecek; bu yüzden veritabanına/ürüne özel dillere kıyasla çok daha gerçekleştirilebilir olduğunu düşünüyorum. PRQL geliştiricisiyim.
    • En iyi karşı argüman: https://www.scattered-thoughts.net/writing/against-sql/

  • Önceki Show HN: https://news.ycombinator.com/item?id=31897430
    “Show HN: PRQL 0.2 – a better SQL”, 27 Haziran 2022’de maximilianroos tarafından paylaşılmıştı; 378 puan ve 161 yorum almıştı.
    İlk önerildiği orijinal gönderi: https://news.ycombinator.com/item?id=30060784
    “PRQL – A proposal for a better SQL”, 24 Ocak 2022’de maximilianroos tarafından paylaşılmıştı; 650 puan ve 295 yorum almıştı.

  • Microsoft’un KQL’ini hatırlatıyor: https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/

    • KQL harika; SQL kullandığım her seferinde özlüyorum.
    • Azure kullanırken hissettiğim tek keyif bu.

  • Sözdizimi o kadar da önemli değil; asıl önemli olan optimizer’ın ne yaptığıdır
    Günümüzdeki birçok SQL sorunu eski bir yük gibi görünüyor. Eski motorlar modern söz dizimini iyi işleyemediği için, birçok kişi okunması zor, karmaşık ve derinlemesine iç içe geçmiş sorgular yazmaya alıştı. Örneğin ortak tablo ifadelerine (CTE) bakınca hemen materyalize ediyorlardı; bu yüzden SELECT FROM (SELECT FROM (SELECT FROM A JOIN (SELECT ) B ON A.x=B.x))) gibi eski tarz yaygındı
    Motorların CTE işleme yeteneklerindeki iyileşmeler sayesinde WITH A AS (...), WITH B AS (...), WITH C AS (SELECT y FROM A) SELECT result FROM C WHERE ... gibi anlaşılabilir ve birleştirilebilir sorgular yazmak giderek kolaylaşıyor. Modern window function’lar, SELECT * EXCEPT, daha karmaşık TOP X FOLLOWING gibi özellikler eklendiğinde SQL daha da sadeleşebilir
    Böyle bir ortamda PRQL gibi farklı bir sözdizimi biçiminin küçük iyileştirmelerinin büyük fayda sağlayacağını düşünmüyorum. Emir kipi gibi görünen bir pipeline olarak yeniden yazılabilir, ancak optimizer bunun bazı kısımlarını atabilir. SQL’de daha iyi yapılması gereken şeyler olduğu doğru, fakat biçimsel/sözdizimsel farklar için ikna edici bir gerekçeyi henüz görmedim