SQLは大規模なデータセットを管理するためのツールだと多くの人に見なされているが、その本質は、CやPythonのような汎用言語に備わっている機能を持つプログラミング言語である。汎用的な用途を想定して設計されたものではないが、意外なタスクも実行できる。CedarDBチームはこの能力を示すため、オリジナル版のDOOMをSQLに移植した。WADデータ、つまりエンジン以外のほぼすべての要素は、テーブルに保存された。ゲームの35 fpsを維持しながら画像を生成することは、より困難だった。レンダリング部分は、89個の共通テーブル式（CTE）にまたがる1300行のSQLで構成されている。プロジェクトの残りの部分では、4000行のSQLに加え、キーボード、タイミング、ビットマップ画像の処理に少量のPythonが使われている。DOOMが真の3Dではなく、グラフィックカードが登場する前に開発されたことが、SQLに適したデータ変換を可能にしている。コードはGitHubに公開されており、正規表現とMicrosoft Wordで作られたバージョンもある。
なぜ重要なのか
この取り組みは、SQLがデータのクエリと管理に限定されたものと見なされていることが、SQLという言語の表現力を十分に反映していない可能性を示している。特に、データベース開発者やプログラミング言語の限界を検証する人々にとって、ゲームロジックのような異例のワークロードをリレーショナル構造でどのようにモデル化できるのかを示す具体例となっている。これが可能になった決定的な要因は、DOOMが真の3Dを使用しない構造であり、グラフィックスハードウェアが登場する前に開発されたことだ。そのため、今回の結果は、あらゆるグラフィックスアプリケーションがSQLで同様に動作することを意味するわけではない。GitHubにあるコードと、正規表現およびMicrosoft Wordを使って作成されたその他のバージョンは、同じアイデアを異なるツールでどのように検証できるかを示している。残る疑問は、このアプローチが楽しいデモンストレーションを超えて、どのような実用的なタスクで意味を持つのかという点だ。
背景
DOOMは、FikirPilotのアーカイブにおいて新しい名前ではない。過去90日間に、この名前が登場するニュースを3本公開しており、最も新しいものは2026年9月15日付だ。