# SQL의 문제점과 해결 방안: SQL의 파이프 문법

> Clean Markdown view of GeekNews topic #16466. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=16466](https://news.hada.io/topic?id=16466)
- GeekNews Markdown: [https://news.hada.io/topic/16466.md](https://news.hada.io/topic/16466.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-08-26T09:55:49+09:00
- Updated: 2024-08-26T09:55:49+09:00
- Original source: [research.google](https://research.google/pubs/sql-has-problems-we-can-fix-them-pipe-syntax-in-sql/)
- Points: 13
- Comments: 11

## Summary

SQL의 복잡성과 학습 곡선을 줄이기 위해 GoogleSQL은 파이프 구조의 데이터 흐름 구문을 도입하여 기존 SQL의 문제점을 해결하고자 합니다. 이 접근 방식은 SQL의 유연성을 크게 향상시키며, 기존 SQL과의 완전한 호환성을 유지하면서도 데이터를 더 쉽게 필터링, 집계, 정렬할 수 있게 합니다. 또한, 사용자들은 복잡한 쿼리를 선형적으로 표현하고, 편집과 디버깅 작업이 용이해지는 등 긍정적인 피드백을 받고 있습니다.

## Topic Body

- SQL은 50년 동안 구조적 데이터 처리의 기본 언어로 자리 잡았지만 배우기 어렵고, 사용하기 까다로우며, 확장하기 어려움  
- 기존 SQL의 문제점 : 구문 순서의 강제성, 중복된 구문, 서브쿼리 사용 필요성, '안쪽에서 바깥쪽으로'의 데이터 흐름, 확장성의 부족 등  
- GoogleSQL에서는 SQL의 문제를 해결하기 위해 SQL을 확장하는 접근 방식을 채택  
  - 파이프 구조의 데이터 흐름 구문을 SQL에 도입하여 기존 SQL의 문제를 해결하고자 함  
  - SQL을 기존의 생태계를 유지하면서도 보다 유연하게 학습하고 사용할 수 있으며, 기존 SQL과의 완전한 호환성을 유지함  
    - 기존 SQL 연산자를 재사용하고 파이프로 임의의 순서로 구성할 수 있게 함   
    - 각 파이프 연산자는 입력 테이블만 볼 수 있어 범위가 명확함  
    - 선언적 의미론을 유지함  
    - 관계 대수와 일대일 대응이 가능해짐  
    - 테이블 값 함수를 이용한 확장성이 개선됨  
  - 예를 들어, 다단계 집계를 서브쿼리 없이 연속적으로 표현할 수 있음  
  - 파이프 구문을 사용한 SQL은 학습과 사용이 더 쉽고, 다양한 연산자들을 임의의 순서로 적용할 수 있어 유연성이 크게 향상됨  
  - 파이프 연산자는 순차적으로 작동하며, 이를 통해 사용자는 데이터를 보다 쉽게 필터링, 집계, 정렬할 수 있음  
- GoogleSQL에서의 사용 경험  
  - 사용자들의 꾸준한 채택과 긍정적인 피드백을 받음   
  - 복잡한 쿼리도 선형적으로 표현 가능  
  - 편집과 디버깅 작업에 용이함  
  - IDE 도구 지원이 개선됨  
  - SQL 코드 생성기와 변환기에 유리함  
  - AI 적용에 잠재적 장점이 있음  
- 구현과 향후 계획  
  - GoogleSQL에서 파이프 문법을 공유 컴포넌트로 구현함  
  - 기존 쿼리 엔진들은 파이프 문법을 쉽게 활성화할 수 있음  
  - BigQuery와 Spanner에서 외부적으로 지원하는 것을 검토 중  
  - 향후 SQL 표준에 포함되는 것을 모색할 만한 가치가 있음  
  
### GN⁺의 의견  
  
- **파이프 구문의 장점**: SQL의 복잡성을 해결할 수 있는 강력한 도구로 작용하며, 특히 데이터 흐름을 직관적으로 표현할 수 있어 SQL 사용성을 크게 개선할 수 있음.  
- **기존 SQL과의 호환성**: 기존 SQL을 대체하는 것이 아닌, SQL을 개선하는 방향으로 접근하여 학습 곡선을 줄이고, 기존 코드와의 호환성을 유지할 수 있음.  
- **도입 시 고려 사항**: 파이프 구문을 채택할 때는 성능에 미치는 영향과 도구 지원 수준을 고려해야 하며, 특히 대규모 쿼리에서 파이프 구문의 장점을 최대한 활용할 수 있음.  
- **유사 프로젝트와의 비교**: Pandas와 같은 DataFrame API에서도 파이프 구조가 사용되지만, SQL과의 차별점은 SQL의 선언적 의미론과의 결합임. SQL 시스템의 확장성과 성능을 유지하면서 이러한 기능을 사용할 수 있음.

## Comments



### Comment 28325

- Author: dkang
- Created: 2024-08-26T22:21:12+09:00
- Points: 1

파이프에 캐럿이라니 뭔가 오른손이 아플것같은 조합🤣  
지금 SQL에 뭔가 개선이 필요하긴 하죠   
한 3-40년간 개선안을 못찾은게 문제이긴 한데요..

### Comment 28319

- Author: savvykang
- Created: 2024-08-26T15:46:00+09:00
- Points: 1

SQL 추가 문법에 대해서 생태계를 구글이 이끌어야될 것 같은데 과연 사업부가 이걸 지속시킬까요?

### Comment 28311

- Author: chusine
- Created: 2024-08-26T13:25:51+09:00
- Points: 1

dplyr 이군요 ㅋㅋㅋㅋ

### Comment 28309

- Author: koreaisbest
- Created: 2024-08-26T12:56:47+09:00
- Points: 2

왜 구글이 한다고 하면 망할 것 같은 느낌만 들지..  
제미나이는 잼민이처럼 답변해서 쓰기도 싫던데

### Comment 28308

- Author: ilotoki0804
- Created: 2024-08-26T12:48:05+09:00
- Points: 1

ORM들이 취하는 접근 방식과 비슷한 것 같네요

### Comment 28299

- Author: winterjung
- Created: 2024-08-26T11:24:23+09:00
- Points: 1

페이퍼의 아래 예제만 봐도 확실히 google sql이 읽기 편하긴 하네요.  
  
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;  
```

### Comment 28435

- Author: mwma91
- Created: 2024-08-30T10:30:05+09:00
- Points: 1
- Parent comment: 28299
- Depth: 1

C#의 LINQ가 생각나네요. SQL 쓸 때마다 항상 SELECT 순서가 FROM, WHERE 뒤로 바뀌었으면 좋겠다는 생각을 했었는데....  
처음엔 익숙하지 않아서 어색해도 천천히 읽어보면 흐름이 훨씬 자연스럽게 느껴집니다.

### Comment 28364

- Author: regentag
- Created: 2024-08-27T20:08:14+09:00
- Points: 1
- Parent comment: 28299
- Depth: 1

SQL쪽이 읽기에 더 좋은것 같네요.

### Comment 28358

- Author: leftliber
- Created: 2024-08-27T16:56:55+09:00
- Points: 1
- Parent comment: 28299
- Depth: 1

저는 SQL쪽이 훨씬 읽기 편한데요. ㅎㅎ SQL로 시작한 분들은 대부분 그러할듯...

### Comment 28384

- Author: superwoou
- Created: 2024-08-28T10:48:24+09:00
- Points: 1
- Parent comment: 28358
- Depth: 2

저도 익숙한게 더 읽기 쉽긴 하네요.. ㅋㅋ

### Comment 28283

- Author: neo
- Created: 2024-08-26T09:55:49+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=41338877) 
- SQL 파이프 구문이 더 읽기 쉬워졌음
- Google에서 SQL 쿼리를 작성할 때 파이프 구문이 유용했음
- SQL 파이프 구문이 일반화되기를 희망함
- Google AI Studio에서 PDF를 HTML로 변환해본 결과가 좋았음
- 20년 넘게 SQL을 사용해왔지만 여전히 특정 쿼리를 표현하는 데 어려움이 있음
- Google의 오픈 소스 ZetaSQL 프로젝트가 파이프 구문 문서를 추가했음
- SQL의 구문 불만은 우선순위가 낮음
  - 대수적 데이터 타입, 진정한 불리언 논리, 함수형 구성 등의 기능이 필요함
- SQL 작성의 어려움을 줄이기 위한 많은 시도가 있었지만 성공하지 못했음
  - 저자들의 접근 방식은 점진적이고 기존 SQL 사용자에게 적합함
- 파이프라인 구문은 현재 상태보다 나음
  - 쿼리 실행을 작업의 방향 그래프로 모델링하는 구문이 더 좋을 것임
    - 조인은 두 개 이상의 데이터 스트림을 소비하고 하나의 데이터 스트림을 생성하는 "교차 참조" 작업으로 모델링할 수 있음
    - CTE는 여러 데이터 스트림을 생성하는 것으로 모델링할 수 있음
    - 재귀 CTE는 실행 그래프의 사이클로 모델링할 수 있음
- Elixir와 유사함
  - 기존 SQL 구문이 지원된다면 괜찮지만, 여러 JOIN, 서브쿼리 및 집계가 포함된 쿼리는 가독성이 떨어질 수 있음
- PRQL과 Splunk의 SPL을 떠올리게 함