Masalah dan Solusi SQL: Sintaks Pipa pada SQL

• Selama 50 tahun, SQL telah menjadi bahasa dasar untuk pemrosesan data terstruktur, tetapi sulit dipelajari, rumit digunakan, dan sukar diperluas
• Masalah SQL yang ada saat ini: urutan sintaks yang dipaksakan, sintaks yang berulang, perlunya menggunakan subquery, alur data "dari dalam ke luar", kurangnya ekstensibilitas, dan lain-lain
• Di GoogleSQL, pendekatan yang diambil untuk mengatasi masalah SQL adalah dengan memperluas SQL
  • Dengan memperkenalkan sintaks alur data berbentuk pipa ke dalam SQL, mereka berupaya menyelesaikan masalah-masalah SQL yang ada
  • SQL menjadi lebih fleksibel untuk dipelajari dan digunakan sambil tetap mempertahankan ekosistem yang ada, serta menjaga kompatibilitas penuh dengan SQL yang sudah ada
    • Operator SQL yang ada digunakan kembali dan dapat disusun dengan pipa dalam urutan apa pun
    • Setiap operator pipa hanya dapat melihat tabel input sehingga cakupannya jelas
    • Tetap mempertahankan semantik deklaratif
    • Memungkinkan korespondensi satu banding satu dengan aljabar relasional
    • Ekstensibilitas ditingkatkan melalui table-valued function
  • Sebagai contoh, agregasi multistage dapat dinyatakan secara berurutan tanpa subquery
  • SQL yang menggunakan sintaks pipa lebih mudah dipelajari dan digunakan, serta fleksibilitasnya meningkat secara signifikan karena berbagai operator dapat diterapkan dalam urutan apa pun
  • Operator pipa bekerja secara berurutan, sehingga pengguna dapat lebih mudah memfilter, mengagregasi, dan mengurutkan data
• Pengalaman penggunaan di GoogleSQL
  • Mendapat adopsi yang konsisten dari pengguna serta umpan balik yang positif
  • Query yang kompleks pun dapat diekspresikan secara linear
  • Memudahkan pekerjaan penyuntingan dan debugging
  • Dukungan alat IDE meningkat
  • Menguntungkan untuk generator dan konverter kode SQL
  • Memiliki potensi keuntungan untuk penerapan AI
• Implementasi dan rencana ke depan
  • Sintaks pipa diimplementasikan di GoogleSQL sebagai komponen bersama
  • Mesin query yang ada dapat dengan mudah mengaktifkan sintaks pipa
  • Sedang dipertimbangkan untuk didukung secara eksternal di BigQuery dan Spanner
  • Layak dieksplorasi untuk dimasukkan ke standar SQL di masa depan

Pendapat GN⁺

• Keunggulan sintaks pipa: Dapat berperan sebagai alat yang kuat untuk mengatasi kompleksitas SQL, terutama karena mampu mengekspresikan alur data secara intuitif sehingga kegunaan SQL bisa meningkat secara signifikan.
• Kompatibilitas dengan SQL yang ada: Pendekatannya bukan menggantikan SQL lama, melainkan memperbaikinya, sehingga dapat mengurangi kurva belajar dan menjaga kompatibilitas dengan kode yang sudah ada.
• Hal yang perlu dipertimbangkan saat adopsi: Saat mengadopsi sintaks pipa, perlu mempertimbangkan dampaknya terhadap performa dan tingkat dukungan alat, terutama karena pada query berskala besar keunggulan sintaks pipa dapat dimanfaatkan secara maksimal.
• Perbandingan dengan proyek serupa: Struktur pipa juga digunakan pada DataFrame API seperti Pandas, tetapi perbedaannya dengan SQL adalah penggabungannya dengan semantik deklaratif SQL. Fitur ini dapat digunakan sambil tetap mempertahankan ekstensibilitas dan performa sistem SQL.

[dkang]

Caret di pipe? Kombinasi ini rasanya bakal bikin tangan kanan pegal 🤣
Memang saat ini SQL perlu semacam perbaikan.
Masalahnya, selama 30-40 tahun ini belum juga ditemukan usulan perbaikan yang tepat..

[savvykang]

Untuk tambahan sintaks SQL, rasanya Google perlu memimpin ekosistemnya, tetapi apakah divisi bisnis benar-benar akan mempertahankan ini?

[chusine]

Itu dplyr ya wkwkwk

[koreaisbest]

Kenapa ya kalau Google yang melakukannya, rasanya malah bakal gagal..
Gemini juga menjawab kayak bocah, jadi malas dipakai juga

[ilotoki0804]

Sepertinya mirip dengan pendekatan yang diambil ORM.

[winterjung]

Hanya dengan melihat contoh di paper di bawah ini pun sudah cukup jelas bahwa Google SQL memang lebih mudah dibaca.

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]

Mengingatkan saya pada LINQ di C#. Setiap kali memakai SQL, saya selalu berpikir akan lebih baik kalau urutan SELECT dipindah ke belakang FROM, WHERE....
Awalnya memang terasa canggung karena belum terbiasa, tetapi kalau dibaca pelan-pelan, alurnya terasa jauh lebih alami.

[regentag]

Menurut saya, sisi SQL tampaknya lebih enak dibaca.

[leftliber]

Menurut saya, SQL jauh lebih enak dibaca. Hehe, mungkin kebanyakan orang yang mulai dari SQL juga merasa begitu...

[superwoou]

Saya juga merasa yang sudah familiar memang lebih mudah dibaca.. wkwk

[GN⁺]

Opini Hacker News

• Sintaks pipe SQL menjadi lebih mudah dibaca
• Saat menulis kueri SQL di Google, sintaks pipe terasa berguna
• Berharap sintaks pipe SQL menjadi umum digunakan
• Hasil mencoba mengonversi PDF ke HTML di Google AI Studio cukup bagus
• Sudah menggunakan SQL selama lebih dari 20 tahun, tetapi masih kesulitan mengekspresikan kueri tertentu
• Proyek open source ZetaSQL milik Google telah menambahkan dokumentasi sintaks pipe
• Keluhan tentang sintaks SQL bukan prioritas utama
  • Fitur seperti algebraic data type, logika boolean yang sesungguhnya, dan komposisi fungsional dibutuhkan
• Banyak upaya telah dilakukan untuk mengurangi kesulitan menulis SQL, tetapi belum berhasil
  • Pendekatan penulis bersifat bertahap dan cocok untuk pengguna SQL yang sudah ada
• Sintaks pipeline lebih baik daripada kondisi saat ini
  • Sintaks yang memodelkan eksekusi kueri sebagai graf terarah dari pekerjaan akan lebih baik
    • Join dapat dimodelkan sebagai pekerjaan "cross-reference" yang mengonsumsi dua atau lebih aliran data dan menghasilkan satu aliran data
    • CTE dapat dimodelkan sebagai sesuatu yang menghasilkan beberapa aliran data
    • Recursive CTE dapat dimodelkan sebagai siklus dalam graf eksekusi
• Mirip dengan Elixir
  • Jika sintaks SQL yang ada tetap didukung, itu tidak masalah, tetapi kueri yang berisi banyak JOIN, subkueri, dan agregasi bisa menjadi kurang mudah dibaca
• Mengingatkan pada PRQL dan SPL milik Splunk