13 puan yazan GN⁺ 2024-08-26 | 11 yorum | WhatsApp'ta paylaş
  • SQL, 50 yıldır yapılandırılmış veri işlemenin temel dili olarak konumunu koruyor; ancak öğrenmesi zor, kullanımı zahmetli ve genişletilmesi güç
  • Mevcut SQL'in sorunları: sözdizimi sırasının dayatılması, yinelenen sözdizimi, alt sorgu kullanma gerekliliği, "içten dışa" veri akışı ve genişletilebilirlik eksikliği
  • GoogleSQL, SQL'in sorunlarını çözmek için SQL'i genişleten bir yaklaşımı benimsiyor
    • Veri akışını pipe yapısıyla ifade eden bir sözdizimini SQL'e getirerek mevcut SQL sorunlarını çözmeyi hedefliyor
    • Mevcut ekosistemi korurken SQL'in daha esnek biçimde öğrenilmesini ve kullanılmasını sağlıyor; ayrıca mevcut SQL ile tam uyumluluğu sürdürüyor
      • Mevcut SQL operatörlerini yeniden kullanıyor ve bunların pipe ile istenen sırada birleştirilmesine olanak tanıyor
      • Her pipe operatörü yalnızca girdi tablosunu görebildiği için kapsam net oluyor
      • Bildirimsel semantik korunuyor
      • İlişkisel cebirle bire bir eşleşme mümkün hale geliyor
      • Tablo değerli fonksiyonlar sayesinde genişletilebilirlik iyileşiyor
    • Örneğin çok aşamalı toplulaştırmalar, alt sorgu olmadan art arda ifade edilebiliyor
    • Pipe sözdizimi kullanılan SQL, öğrenme ve kullanım açısından daha kolay; ayrıca çeşitli operatörlerin istenen sırada uygulanabilmesi sayesinde esneklik önemli ölçüde artıyor
    • Pipe operatörleri sıralı şekilde çalışıyor; bu sayede kullanıcılar veriyi daha kolay filtreleyebiliyor, toplulaştırabiliyor ve sıralayabiliyor
  • GoogleSQL'deki kullanım deneyimi
    • Kullanıcılardan istikrarlı benimseme ve olumlu geri bildirim alındı
    • Karmaşık sorgular bile doğrusal biçimde ifade edilebiliyor
    • Düzenleme ve hata ayıklama işlemleri için elverişli
    • IDE araç desteği iyileşiyor
    • SQL kod üreticileri ve dönüştürücüler için avantaj sağlıyor
    • Yapay zeka uygulamaları için potansiyel avantajlar barındırıyor
  • Uygulama ve gelecek planları
    • Pipe sözdizimi GoogleSQL'de ortak bir bileşen olarak uygulanmış durumda
    • Mevcut sorgu motorları pipe sözdizimini kolayca etkinleştirebilir
    • BigQuery ve Spanner'da dışa açık destek sunulması değerlendiriliyor
    • Gelecekte SQL standardına dahil edilmesi araştırmaya değer olabilir

GN⁺ görüşü

  • Pipe sözdiziminin avantajları: SQL'in karmaşıklığını çözebilecek güçlü bir araç işlevi görüyor; özellikle veri akışını sezgisel biçimde ifade edebilmesi, SQL'in kullanılabilirliğini büyük ölçüde iyileştirebilir.
  • Mevcut SQL ile uyumluluk: SQL'i değiştirmek yerine iyileştirme yönünde bir yaklaşım benimsendiği için öğrenme eğrisi azaltılabilir ve mevcut kodla uyumluluk korunabilir.
  • Benimserken dikkat edilmesi gerekenler: Pipe sözdizimi benimsenirken performansa etkisi ve araç desteğinin düzeyi dikkate alınmalı; özellikle büyük ölçekli sorgularda pipe sözdiziminin avantajlarından en yüksek verim alınabilir.
  • Benzer projelerle karşılaştırma: Pandas gibi DataFrame API'lerinde de pipe yapısı kullanılıyor; ancak SQL'den farkı, SQL'in bildirimsel semantiğiyle birleşmesidir. SQL sistemlerinin genişletilebilirliği ve performansı korunurken bu işlevlerden yararlanılabilir.

11 yorum

 
dkang 2024-08-26

Pipe ile caret bir araya gelince insanın sağ eli ağrıyacakmış gibi hissettiriyor 🤣
Gerçi şu an SQL'de gerçekten bazı iyileştirmelere ihtiyaç var
Ama asıl sorun, 30-40 yıldır bir iyileştirme önerisi bulunamamış olması..

 
savvykang 2024-08-26

SQL'e ek sözdizimi konusunda ekosisteme Google'ın yön vermesi gerekiyormuş gibi görünüyor, ama acaba iş birimi bunu sürdürecek mi?

 
chusine 2024-08-26

dplyr işte hahaha

 
koreaisbest 2024-08-26

Google yapıyor denince neden sadece batacakmış gibi bir his geliyor bana..
Gemini de ergen gibi cevap verdiği için kullanasım gelmiyor

 
ilotoki0804 2024-08-26

ORM'lerin benimsediği yaklaşıma benziyor gibi.

 
winterjung 2024-08-26

Makalede aşağıdaki örneğe bakınca bile Google SQL'in okunmasının gerçekten daha kolay olduğu anlaşılıyor.

standart 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

C#'taki LINQ'ü hatırlatıyor. SQL kullandığım her seferinde, keşke SELECT sırası hep FROM, WHERE'den sonra gelse diye düşünürdüm....
Başta alışık olmadığım için tuhaf gelse de, yavaş yavaş okuyunca akışın çok daha doğal hissettirdiğini fark ediyorsunuz.

 
regentag 2024-08-27

SQL tarafı okunabilirlik açısından daha iyi görünüyor.

 
leftliber 2024-08-27

Bence SQL tarafı çok daha rahat okunuyor. :) SQL ile başlayanların çoğu muhtemelen böyle düşünüyordur...

 
superwoou 2024-08-28

Ben de alışık olduğum şeyin daha okunması kolay geliyor.. haha

 
GN⁺ 2024-08-26
Hacker News görüşleri
  • SQL pipe sözdizimi daha okunabilir hale gelmiş
  • Google'da SQL sorguları yazarken pipe sözdizimi kullanışlı olmuş
  • SQL pipe sözdiziminin yaygınlaşması umuluyor
  • Google AI Studio'da PDF'yi HTML'ye dönüştürmeyi denediğinde sonuç iyi olmuş
  • 20 yılı aşkın süredir SQL kullanıyor ama hâlâ bazı sorguları ifade etmekte zorlanıyor
  • Google'ın açık kaynaklı ZetaSQL projesi pipe sözdizimi belgelerini eklemiş
  • SQL'in sözdizimiyle ilgili şikâyetlerin önceliği düşük
    • cebirsel veri tipleri, gerçek boolean mantığı ve fonksiyonel bileşim gibi özelliklere ihtiyaç var
  • SQL yazmanın zorluğunu azaltmak için birçok girişim olmuş ama başarılı olamamış
    • yazarların yaklaşımı kademeli ve mevcut SQL kullanıcıları için uygun
  • pipeline sözdizimi mevcut duruma göre daha iyi
    • sorgu yürütmesini işlerin yönlü grafiği olarak modelleyen bir sözdizimi daha iyi olurdu
      • join, iki veya daha fazla veri akışını tüketip bir veri akışı üreten bir "çapraz başvuru" işlemi olarak modellenebilir
      • CTE, birden fazla veri akışı üreten bir yapı olarak modellenebilir
      • özyinelemeli CTE, yürütme grafiğindeki döngü olarak modellenebilir
  • Elixir'e benziyor
    • mevcut SQL sözdizimi destekleniyorsa sorun değil, ancak birden fazla JOIN, alt sorgu ve toplulaştırma içeren sorguların okunabilirliği düşebilir
  • PRQL ve Splunk'ın SPL'ini hatırlatıyor