MAD
今後の方向性：レポートはテーブルである
最終更新：2026-10-29。本ページは、MADが今後成長していく設計上の方向性を示すものです。ここに記述されているコンポジション（合成）機能やマイグレーション機構はまだ実装されていません。データオブジェクトモデルの基礎となる設計はdocs/project/MAD_DATA_OBJECT.md、作業記録はdocs/project/MAD_FUTURE.md、プロダクトのウィッシュリストはdocs/project/TODO.mdにあります。
現在のMAD
.madドキュメントはレポートの定義です。すなわち、スキーマスナップショット、クエリグラフ（テーブル、結合、グループ化、フィルタ）、およびバンド型レイアウトツリーを保持します。更新（リフレッシュ）時には、エンジンがグラフをSQLにコンパイルし、行データを一度だけ読み取ってコンパニオンSQLiteキャッシュ（.maddb + .mdcache）にマテリアライズ（実体化）します。行データは意図的にドキュメントの外に置かれ、定義ファイル自体は100 KB未満に保たれます。
ここから導かれる重要な帰結があります。それは、レポートとはデータソースからテーブルへの関数であるということです。すべてのドライバはスキーマと行データをテーブル形式で返し、レポートの出力もまたスキーマ（MADDataColumn）とテーブル形式の行データ（MADDataTableFast）そのものです。エンジンはすでにこの両者を同じものとして扱っています。
目指す姿
レポートの定義とそのマテリアライズされた出力の間のループを閉じることで、次の4つの能力が解放されます：
1. アドホックなデータベーステーブルとしての.madファイル
通常のデータベースでは、employeeやsales_dataのようなベーステーブルからSELECTします。一方、レポートは複数のテーブルを結合し、その出力はアドホックにマテリアライズされたSQLiteテーブルとなります。現状では、あるクエリから別のレポートの出力を参照することはできません。結果キャッシュ自体は存在しますが、アドレス指定可能な識別子ではなくファイル名ハッシュをキーとしているためです。この出力をアドレス指定可能にすると、次のことが実現します：
レポートの結果そのものがデータベーステーブルとなり、他のレポートやクエリから
SELECTやJOINの対象として利用できるようになる。
レポートの上に構築されたレポートは派生テーブルのDAG（有向非巡回グラフ）となり、レポートを設計することがそのまま再利用可能なデータソースを設計することになる、ポータブルなセマンティックレイヤーを実現します。
2. 単一レポート内での複数データソース（サーバー不要のフェデレーション）
すべてのドライバ（MADMySQL、MADPostgres、MADTdsClient、MADSqlite3）は、それぞれの結果セットを同じローカルSQLiteテーブル表現にマテリアライズします。1つのドキュメントが複数のクエリ定義を保持し、それぞれの出力をテーブルとして参照できるようになれば、1つのレポート内でPostgreSQLのテーブルとSQL ServerのテーブルとMySQLのテーブルを結合できるようになります。中間に重厚なフェデレーションサーバーを置くことなく、SQLite上でローカルにフェデレーションが完結します。スナップショットそのものがフェデレーションとなるのです。
3. 1つのパラダイムとしての「紙」——生データ上のネイティブUIKitビュー
バンド型のページ分割レイアウト（Report Header、Page Header、Groupings、Detail、Footers）は、紙への印刷のために発明されたものです。しかし、.madのレイアウトはパラメトリックなデータであり、.maddbの行キャッシュはデバイス上のローカルSQLiteであるため、紙のページはレポートを表現する1つの方法にすぎません。印刷を目的としない場面では、同じ定義とローカルキャッシュを使ってインタラクティブなネイティブUIKitビューや生データエクスプローラを描画できます——一度レイアウトすれば、紙のページとしてもネイティブUIとしても表示できます。
4. レガシーなCrystal Reports（.rpt）からオープンな.madファイルへの変換
Crystal Reports（.rpt）や類似のレガシーなレポートファイルが今なお何千もの企業に根強く残っているのは、その「バンド型セクション＋リレーショナルクエリグラフ」モデルを共有するオープンでポータブルなエンジンが存在しないためです。MADはまさにその構造的パラダイムの上に構築されており、かつ定義をオープンで文書化されたSQLite-in-tar形式で保存するため、レガシーな.rptドキュメントを.madファイルへ変換するインポータによって、プロプライエタリな旧来型レポーティング基盤からの直接的な移行パスを提供できます。
すでに存在するもの
最もコストのかかる部分はすでに構築されています。ポータブルな定義、決定論的なSQL生成とパース、ポータブルなマテリアライズ形式（SQLite）、4つのデータベースドライバ、そしてiOS/macOS上でネイティブに動作しLinux上でヘッドレスに動作する単一のエンジンです。
本ページの位置づけ
これはリリースの約束ではありません。本ページは設計の方向性を記録したものであり、具体的な設計とタスクキューはdocs/project/にあります。ここで述べた機能は、リポジトリ内の他のすべての機能と同様に、設計・テスト・文書化が完了して初めて出荷されます。
このページは英語原文の日本語翻訳です。内容に相違がある場合は、英語原文が優先されます。