Vấn đề của SQL và cách khắc phục: cú pháp pipe trong SQL

 (research.google)
13 điểm bởi GN⁺ 2024-08-26 | 11 bình luận | Chia sẻ qua WhatsApp
  • SQL đã giữ vai trò là ngôn ngữ nền tảng cho xử lý dữ liệu có cấu trúc suốt 50 năm, nhưng lại khó học, khó sử dụng và khó mở rộng
  • Các vấn đề của SQL hiện tại: tính bắt buộc của thứ tự cú pháp, cú pháp lặp lại, sự cần thiết phải dùng subquery, luồng dữ liệu "từ trong ra ngoài", thiếu khả năng mở rộng, v.v.
  • Trong GoogleSQL, Google áp dụng cách tiếp cận mở rộng SQL để giải quyết các vấn đề của SQL
    • Đưa cú pháp luồng dữ liệu dạng pipe vào SQL để giải quyết các vấn đề của SQL hiện tại
    • Có thể học và sử dụng SQL linh hoạt hơn trong khi vẫn giữ nguyên hệ sinh thái hiện có và duy trì khả năng tương thích hoàn toàn với SQL hiện tại
      • Tái sử dụng các toán tử SQL hiện có và cho phép ghép chúng bằng pipe theo thứ tự tùy ý
      • Mỗi toán tử pipe chỉ nhìn thấy bảng đầu vào nên phạm vi rất rõ ràng
      • Vẫn giữ ngữ nghĩa khai báo
      • Có thể ánh xạ 1:1 với đại số quan hệ
      • Cải thiện khả năng mở rộng bằng hàm giá trị bảng
    • Ví dụ, có thể biểu diễn tổng hợp nhiều giai đoạn liên tiếp mà không cần subquery
    • SQL dùng cú pháp pipe dễ học và dễ dùng hơn, đồng thời độ linh hoạt được cải thiện đáng kể vì có thể áp dụng nhiều toán tử khác nhau theo thứ tự tùy ý
    • Các toán tử pipe hoạt động tuần tự, nhờ đó người dùng có thể lọc, tổng hợp và sắp xếp dữ liệu dễ dàng hơn
  • Trải nghiệm sử dụng trong GoogleSQL
    • Nhận được mức độ chấp nhận ổn định từ người dùng và phản hồi tích cực
    • Có thể biểu diễn truy vấn phức tạp theo cách tuyến tính
    • Thuận tiện cho việc chỉnh sửa và debug
    • Hỗ trợ công cụ IDE được cải thiện
    • Có lợi cho trình tạo và trình chuyển đổi mã SQL
    • Có tiềm năng mang lại lợi thế cho việc áp dụng AI
  • Triển khai và kế hoạch sắp tới
    • Cú pháp pipe trong GoogleSQL được triển khai dưới dạng component dùng chung
    • Các query engine hiện có có thể kích hoạt cú pháp pipe một cách dễ dàng
    • Đang xem xét hỗ trợ công khai trong BigQuery và Spanner
    • Đáng để cân nhắc đưa vào tiêu chuẩn SQL trong tương lai

Ý kiến của GN⁺

  • Ưu điểm của cú pháp pipe: Đây có thể là một công cụ mạnh để giải quyết độ phức tạp của SQL, đặc biệt vì nó cho phép biểu diễn luồng dữ liệu một cách trực quan, từ đó cải thiện đáng kể tính dễ dùng của SQL.
  • Khả năng tương thích với SQL hiện tại: Đây không phải là thay thế SQL hiện có mà là cách tiếp cận cải tiến SQL, nhờ đó có thể giảm đường cong học tập và vẫn giữ được khả năng tương thích với mã hiện tại.
  • Các điểm cần cân nhắc khi áp dụng: Khi áp dụng cú pháp pipe, cần xem xét ảnh hưởng đến hiệu năng và mức độ hỗ trợ của công cụ; đặc biệt với các truy vấn quy mô lớn, có thể tận dụng tối đa ưu điểm của cú pháp pipe.
  • So sánh với các dự án tương tự: Cấu trúc pipe cũng được dùng trong các DataFrame API như Pandas, nhưng điểm khác biệt so với SQL là sự kết hợp với ngữ nghĩa khai báo của SQL. Có thể sử dụng tính năng này trong khi vẫn duy trì khả năng mở rộng và hiệu năng của hệ thống SQL.

Bài viết liên quan

11 bình luận

 
dkang 2024-08-26

Pipe mà lại thêm dấu mũ nữa thì đúng là kiểu phối hợp khiến tay phải đau thật 🤣
Đúng là bây giờ SQL cũng cần có chút cải thiện
Vấn đề là suốt 30-40 năm rồi vẫn chưa tìm ra được phương án cải tiến nào thật sự ổn..
 
savvykang 2024-08-26

Có vẻ như Google cần phải dẫn dắt hệ sinh thái về phần cú pháp bổ sung cho SQL, nhưng liệu bộ phận kinh doanh có tiếp tục duy trì việc này không?
 
chusine 2024-08-26

Giống dplyr nhỉ hahaha
 
koreaisbest 2024-08-26

Không hiểu sao cứ hễ Google làm là lại có cảm giác sẽ thất bại.. Gemini thì trả lời kiểu trẻ con nên cũng chẳng muốn dùng nữa
 
ilotoki0804 2024-08-26

Có vẻ khá giống với cách tiếp cận mà các ORM áp dụng.
 
winterjung 2024-08-26

Chỉ cần nhìn ví dụ bên dưới trong bài báo là cũng đủ thấy Google SQL thực sự dễ đọc hơn.

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 2024-08-30

Làm tôi nhớ đến LINQ của C#. Mỗi lần dùng SQL tôi đều luôn nghĩ rằng sẽ thật tuyệt nếu thứ tự của SELECT được chuyển ra sau FROM, WHERE....
Ban đầu có thể hơi gượng vì chưa quen, nhưng nếu đọc chậm lại thì sẽ thấy mạch đọc tự nhiên hơn rất nhiều.
 
regentag 2024-08-27

Có vẻ bên phía SQL dễ đọc hơn.
 
leftliber 2024-08-27

Tôi thì thấy phía SQL dễ đọc hơn nhiều. Haha, chắc đa số những ai bắt đầu với SQL cũng đều vậy...
 
superwoou 2024-08-28

Tôi cũng thấy cái quen thuộc thì dễ đọc hơn.. haha
 
GN⁺ 2024-08-26
Ý kiến trên Hacker News
  • Cú pháp pipe của SQL dễ đọc hơn
  • Khi viết truy vấn SQL tại Google, cú pháp pipe tỏ ra hữu ích
  • Hy vọng cú pháp pipe của SQL sẽ trở nên phổ biến
  • Kết quả thử chuyển đổi PDF sang HTML trong Google AI Studio cho ra kết quả tốt
  • Đã dùng SQL hơn 20 năm nhưng vẫn thấy khó khi biểu đạt một số truy vấn nhất định
  • Dự án mã nguồn mở ZetaSQL của Google đã bổ sung tài liệu về cú pháp pipe
  • Những bất mãn về cú pháp của SQL không phải ưu tiên cao
    • Cần các tính năng như kiểu dữ liệu đại số, logic boolean thực sự, và khả năng cấu thành theo kiểu hàm
  • Đã có nhiều nỗ lực nhằm giảm độ khó khi viết SQL nhưng chưa thành công
    • Cách tiếp cận của tác giả mang tính từng bước và phù hợp với người dùng SQL hiện có
  • Cú pháp pipeline tốt hơn hiện trạng
    • Một cú pháp mô hình hóa việc thực thi truy vấn dưới dạng đồ thị có hướng của các tác vụ sẽ còn tốt hơn
      • Join có thể được mô hình hóa như một thao tác "tham chiếu chéo" tiêu thụ từ hai hoặc nhiều luồng dữ liệu và tạo ra một luồng dữ liệu
      • CTE có thể được mô hình hóa như việc tạo ra nhiều luồng dữ liệu
      • CTE đệ quy có thể được mô hình hóa như các chu trình trong đồ thị thực thi
  • Tương tự Elixir
    • Nếu cú pháp SQL hiện có vẫn được hỗ trợ thì ổn, nhưng các truy vấn có nhiều JOIN, truy vấn con và phép tổng hợp có thể trở nên khó đọc
  • Gợi nhớ đến PRQL và SPL của Splunk