NoSQL の広がりへの対抗：より現代的なクエリ言語の提言

長年にわたり保管してきたこの草案を再検討し改訂した理由は、新しいクエリ言語（例：Acadia）に関する最近の議論がきっかけとなったからである。著者は以下に述べる通り、SQL が背後にある理念には優れているにもかかわらず実装が時代遅れな点への不満と、プログラマにとって扱いやすい関係型データ処理のための新たなアプローチを提案する。

背景と動機

• 現状の課題
  • SQL は強力な言語だが、実装が頻繁に不器用で時代遅れである。
  • これにより NoSQL が広がる要因の一つとなっている。
  • SQL の理念を参考にした進化系言語こそが、関係型データを扱いやすい鍵となるはずである。
• 著者の経験背景
  • 主に MySQL と Db2 を使用。
  • その他、SQLite、SQL Server、Oracle、PostgreSQL も経験あり（慣れ順）。

---

より優れた構文

開発者が PL/I に基づいた古風な構文に嫌気が差すことはよくあることである。現代のプログラミング言語は C や Python などの美学を取り入れる傾向にある。

• 目指すべき方向性
  • 構文は C、Python のような現代的な美学を採用。
  • Rust などが示唆するように、ML や Prolog の影響も取り入れつつあるべき。
• エラーハンドリングの向上
  • 現在の MySQL パーサ は、問題の所在やエラーの種類を特定できず、「DELIMITER」などの構文異常しか検知しない（苦痛）。
  • 逆に Oracle のような既存実装は、期待する内容を明示することで優れたエラー報告を実現している。
• 言語の影響源
  • これらのアイデアは F# (ML ファミリー)、Erlang (Prolog 的)、Elixir から影響を受けている可能性が高い。

関数型プログラミングへの親和性

SQL の最強の武器は「手動ループではなく、何を実現したいかを書く（4GL 的特性）」にあるが、多くの実装は 1980 年代の手順型スタイルに偏っている。

• 標準ライブラリの貧弱さ
  • Haskell などの関数型パラダイム（遅延評価など）と親和性が高いはずだが、標準ライブラリは貧弱。
  • ストアドプロシージャのサポートが主流になりがちだが、これは本質的に手順型であり SQL の宣言的性質と逆行する。
• デフォルト設定の重要性
  • ユーザーも言語や標準ライブラリによって「状態変化（カーソル）」「プロシージャ優先」といったスタイルを模倣しがちになる。
  • これらを根本から変更するには、デフォルトで関数型アプローチを採用する必要がある。

より透明なクエリプランナ

• 最適化とリスク
  • 強力なコンパイラでコードを最適化できるのは利点だが、わずかなミスでコスト増大の危険性がある。
• ブラックボックスの問題
  • SQL に詳しくない限り、クエリプランナは暗号文のように見える（特に MySQL の

    EXPLAIN

    ツール は劣悪）。
  • 現在の弱点であり、コンピューターサイエンティストが学んできた分野でもある。

より優れたユーザー定義型 (UDT)

ドメインを通じてユーザー定義データ型の指定は SQL 規格のオプションだが、多くの実装で機能が制限されている。

• 現状
  • 通常は範囲やチェック演算子の糖衣包装程度に留まる。
  • PostgreSQL が柔軟なサポートを提供し、最近 Oracle も追随した模様。
• 理論的背景
  • Codd の『The Relational Model』で扱われている概念であり、RDBMS の基礎文献である。
  • PostgreSQL は Ingres の遺産（QUEL を使用）を引き継いでおり、Codd のビジョンに近い実装を選択していると言える。

和型、区別結合型、そしてパターンマッチング

現代の関数型技術（スタックフレーム情報の返却など）を SQL スキーマに適用する例を示す。IBM i システムの管理情報へのアプローチが参考となる。

• 既存の問題点

  • 従来のスキーマでは、排他的な情報を表現するために多数の

    NULL

    値が必要になる（文字列フィールドとして機能）。
  • スキーマ設計の不備と、一度に一つのテーブルでのみ結果を返すという制約が起因する。

• 解決策：パターンマッチングによる SQL

  • 以下に示すのは形式的な例であるが、より簡潔でミスに強いクエリ写作が可能となる。

// 簡略化のため要素を省略（型は外部から宣言可能）
type MachineInterfaceInfo = {
    ActivationGroup: long;
    ASP: long;
    Library: string;
}

// IBM i のプログラムモデル
type FrameType =
    | ILE { MachineInterfaceInfo | ServiceProgram: string; Module: string; }
    | OPM { MachineInterfaceInfo | Program: string; }
    | AIX { Bitness: enum(32 | 64); LibArchive: Option(string); Module: string, Syscall: bool; }
    | Java { MethodType: enum(DirectExecution | Glue | Interp | JIT | MMI); ClassName: string; Signature: Option(string); }

table Frame = {
    ThreadID: long;
    FrameType: FrameType;
    Function: Option(string);
}

// パターンマッチングを用いたフィルタリング
select Function 
from StackInfo("1234/JOB/5678") 
where AIX { Bitness: 64 } = FrameType;

// OPM の場合
select Function 
from StackInfo("1234/JOB/5678") 
where MachineInterfaceInfo { Library: "QSYS" } = FrameType;

• 視覚化への利点
  • 互いに排他的な列のセットを統合可能。
  • スクロール量が大幅に減少し、サブカラムとして表示やタイプに応じた文字列表示が可能になる。

複数の型に対する一致を行う外鍵

Software

、

Version

、

Download

という異なる型のオブジェクトに共通する画像（

Picture

）を管理する場合の構想。通常は Many-to-Many テーブルを作成するが、それを冗長化させることなく実装できる。

• 伝統的なアプローチ
  • 各対象ごとに

    SoftwarePicture

    、

    VersionPicture

    など多くのテーブルを作成し、重複した構造を持つ。
• 提案されたアプローチ：区別結合型 (Discriminated Union) を用いた Many-to-Many テーブル
  • 外鍵が同一の型 (

    key relates to

    ) を持つことで、異なるオブジェクト種別への一致を一元管理可能。

table ObjectPictures = {
    // 外鍵は対象となる型のいずれかと同一の型を持つと仮定される
    PictureID: key relates to (Picture.PictureID);
    ObjectID: key relates to (Software.SoftwareID | Version.VersionID | Download.DownloadID);
}

// インサート例：ダウンロードオブジェクトに画像を関連付け
insert into ObjectPictures (PictureID, ObjectID) 
values (0x1234, DownloadID { 0x1234 });

// ソフトウェアオブジェクトへの関連付け
insert into ObjectPictures (PictureID, ObjectID) 
values (0x1234, SoftwareID { 0x1234 });

// 画像を所有するすべてのオブジェクトを取得（型による区別あり）
select SoftwareID { software_id } from ObjectPictures where PictureID = 0x1234;

// ダウンロードオブジェクトへの関連付けを特定
select PictureID from ObjectPictures where ObjectID = DownloadID { 0x1234 };