SQLの後継に欲しいもの：モダンなリレーショナルクエリ言語の理想
Things I want in a modern relational query language
SQLは強力なアイデアを持つ一方で、実装が古く扱いにくいことがNoSQL普及の一因だと筆者は指摘する。本稿では、より良い構文、関数型プログラミングへの親和性、透過的なクエリプランナー、高度なユーザー定義型、直和型とパターンマッチング、複数型にまたがる外部キーなど、現実のDB運用で直面した課題を踏まえ、モダンなリレーショナルクエリ言語に求める機能を具体例とともに提案する。Acadiaなどの新言語の議論に触発されて公開された、長年温められてきた原稿である。
SQLは強力な言語だが、その背後にあるアイデアゆえに強力なのであって、実装はしばしば不格好で古風だ。
HNでの議論
107- scythmic_waves
ここには、SQLがなぜ欠けているかについての私のお気に入りのエッセイのいくつかと重なる部分があります。
https://www.scattered-thoughts.net/writing/against-sql
その特定の投稿は、欲しいもののリストで終わっているので、元の投稿と最も似ています。しかし、そのサイトには他にも私がかなり楽しんでいるものがあります（ホームアイコンをクリックして、ページ内で「SQL」を検索してください）。
私の個人的な見解では、SQLは、データベースの本質的な複雑さのために置き換えるのが非常に困難であるため、長い間支配し続けるでしょう。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のエラーメッセージがこんなにひどいのか、誰か説明してくれませんか？ 私は日常的に巨大なクエリを扱っていますが、メッセージは事実上「どこかで不正な構文、バカ」です。