SQL은 낡았다: 현대적 관계형 쿼리 언어에 필요한 것들
Things I want in a modern relational query language
SQL은 강력한 아이디어를 기반으로 하지만, 구현이 투박하고 시대에 뒤처져 있다. 이 글은 NoSQL의 등장 원인 중 하나로 SQL의 불편함을 지목하며, 현대 프로그래머의 요구를 충족하는 관계형 쿼리 언어가 갖춰야 할 기능들을 제안한다. 더 나은 문법, 함수형 프로그래밍 지원, 투명한 쿼리 플래너, 개선된 사용자 정의 타입, 합타입과 패턴 매칭, 다형성 외래 키 등을 예시 코드와 함께 소개한다. 저자의 실제 경험을 바탕으로 SQL의 한계를 짚고, 더 선언적이고 표현력 높은 쿼리 언어의 가능성을 모색한다.
프로그래머는 마치 유아와 같아서, 브로콜리보다는 크래프트 디너를 원한다.
HN 토론
107- scythmic_waves
여기 제가 SQL이 왜 부족한지에 대해 좋아하는 에세이들과 겹치는 부분이 있습니다:
https://www.scattered-thoughts.net/writing/against-sql
그 게시물은 특히 희망 목록으로 끝나서 원문과 가장 비슷합니다. 하지만 그 사이트에는 제가 꽤 좋아하는 다른 글들도 있습니다 (홈 아이콘을 클릭하고 페이지에서 "SQL"을 검색해 보세요).
제 개인적인 생각은 SQL이 앞으로도 오랫동안 지배할 것이라는 것입니다. 왜냐하면 데이터베이스의 본질적인 복잡성 때문에 SQL을 대체하는 것이 엄청나게 어렵기 때문입니다. LLM은 이런 상황을 더 악화시킵니다. 왜냐하면 LLM이 자연어를 SQL로 번역하는 데 매우 능숙하기 때문입니다. 이제 SQL이 프로그래머에게 얼마나 짜증나는지가 덜 중요해졌으므로, SQL은 시간이 지남에 따라 어셈블리 언어처럼 될 것입니다: 인간이 직접 다루기에는 복잡하기 때문에 주로 컴퓨터가 작성하는 무언가로 말이죠. SQL이 원래 자연어처럼 읽히도록, 즉 인간에게 쉽도록 설계되었다는 점을 고려하면 이는 매우 아이러니합니다.
- burakemir
저는 원문 작성자와 여기 계신 분들이 이 맥락에서 Mangle Datalog에 대해 어떻게 생각하시는지 정말 궁금합니다. Go 구현은 여기 있습니다: https://codeberg.org/TauCeti/mangle-go 그리고 Rust 구현은 여기 있습니다: https://codeberg.org/TauCeti/mangle-rs
구현이 고성능은 아니지만, 모든 것을 메모리에 넣을 수 있거나 데이터를 조직하고 외부 쿼리를 통해 통합할 수 있다면 많은 사용 사례에서 충분히 작동하는 무언가를 얻을 수 있을 것입니다.
저는 SQL을 대체하려고 시작한 것은 아니며, 채택을 반대하는 것은 아니지만, 그것이 여기서 공유하는 이유는 아닙니다. 오픈소스화는 datalog를 더 널리 알리기 위한 동기에서 비롯되었습니다. 저는 약간의 조사를 했고 특정 특성을 가진 datalog 구현이 필요하다는 것을 알게 되었습니다. 제가 필요한 것에 SQL을 사용하고 싶지 않다는 것은 확실했습니다.
구조화된 타입과 재귀, 그리고 술어에 이름을 붙이고 쿼리를 구성하는 기능이 있습니다... Mangle에는 사용자가 있고 쿼리를 논리 프로그래밍으로 취급하는 접근 방식을 활용하는 몇 가지 애플리케이션이 있습니다.
이 토론에서 얻을 수 있는 통찰 중 하나는 쿼리 언어와 그것이 속한 시스템(DBMS 구현)이 필연적인 성능 요구 사항과 관련하여 거의 분리될 수 없다는 것입니다.
- bastawhiz
메타 코멘트로, 저는 구문 강조 없는 코드 블록도 처리할 수 있고, 줄바꿈이 되는 코드 블록도 처리할 수 있습니다. 하지만 둘 다 긴 댓글과 함께 있으면 그냥 줄 노이즈가 됩니다. 더 이상 어떻게 읽어야 하는지에 대한 유용한 시각적 신호가 없습니다. 제 휴대폰에서는 코드 블록을 의미 있게 파싱하는 것이 불가능합니다.
- mcc1ane
https://www.geldata.com/blog/we-can-do-better-than-sql
(https://news.ycombinator.com/item?id=24106608, https://news.ycombinator.com/item?id=19871051)
- weitendorf
엔터프라이즈 중심이 되기 전의 Spark와 많이 비슷하네요. 제 시절에는 쿼리를 실행하기 위해 scala를 작성했고, 컴파일러와 런타임을 설정하는 방법을 알아내면 우리는 그것을 좋아했습니다!
최근에 Postgres에 빠져들었는데, C 코드를 통해 새로운 타입/연산자 등을 도입하는 것이 얼마나 쉬운지 매우 놀랐습니다. 도메인에 대해 말하는 것이 아닙니다. 그냥 C를 조금 작성하면 원하는 타입을 가질 수 있습니다. 그것은 저에게 '확장'에 대한 신비를 풀어주었습니다. 사실 저는 그것이 본질적으로 사용자 정의 타입/함수에 불과한 것에 대해 적극적으로 해로운 이름이라고 생각합니다 (다른 곳에서 '확장'과 '플러그인'을 다루면서 겪은 경험에 비추어 볼 때 투박하고 지저분하게 들립니다). 더 많은 사람들이 자신만의 Postgres 확장을 작성해 보아야 합니다. 전혀 어렵지 않습니다!
저는 이 분야에서 꽤 오랫동안 일해 왔습니다 (HDFS/spark, Apache Pinot, 사유 소프트웨어, SQLite 위의 실험적인 함수형 ORM). 가장 큰 문제는 관리/운영, 애플리케이션, 그리고 '쿼리' 계층 사이의 인터페이스라고 생각합니다. grpc/protoc 같은 것 (또는 실제로 Spark가 JVM을 사용했던 방식)이 DB에서 클라이언트로의 비-누출 추상화와 더 프로그래밍적/구조화된 인터페이스를 제공하는 데 필요하다고 생각합니다. 더 공유하고 싶지만, 기본적으로 데이터베이스는 반사적 타입 시스템을 가진 일반적인 (메타)파싱이 가능해져야 한다고 생각합니다.
- mikewarot
제 요청은 15년 된 것입니다[1], 실시간 SQL 확장. 쿼리가 데이터베이스에 대한 구독이 되도록 허용하여, 업데이트가 델타로 스트리밍되어 수신 클라이언트에게 전달되게 하는 것입니다. SQL을 사용하는 동안 동일한 쿼리를 반복해서 실행하여 델타를 얻고 처리해야 했던 경우가 많았습니다.
처음부터 그렇게 작업하는 것이 훨씬 더 효율적이지 않을까요?
[1] http://livesql.org/ <--- 2011년의 몇 단락에 불과한 텍스트
- nylonstrung
PRQL은 새로운 쿼리 언어에 대한 최고의 시도 중 하나라고 생각합니다.
저는 substrait로 컴파일되는 Lean4 기반 쿼리 언어를 작업해 왔습니다. 타입과 함수형 프로그래밍에 대한 강력함이 SQL의 인체공학을 상당히 개선할 수 있다고 생각합니다.
- 3eb7988a1663
누가 SQL 오류 메시지가 왜 그렇게 나쁜지 설명해 줄 수 있나요? 저는 종종 거대한 쿼리에서 사실상 "어딘가에 잘못된 구문이 있습니다, 멍청아"라는 메시지를 받습니다.