はじめに
Web開発において、避けて通れないのが「スキーマレスなデータへの対応」です。
「顧客ごとに管理項目を変えたい」「商品カテゴリごとにスペックの定義がバラバラ」といった要件に直面したとき、従来のRDB設計（静的なテーブル定義）はしばしば限界を迎えます。
本連載では、このような「動的な要件」をRDBでどう表現し、システムとしてどう実装していくのか、その核心であるメタデータ駆動設計（Metadata-Driven Architecture）を学んでいきます。
1. なぜ「静的なテーブル設計」は破綻するのか
RDBの基本は「事前にカラム（列）を定義する」ことです。しかし、現代のSaaS開発ではこの前提が揺らぐことが多々あります。
-
スパースデータ（疎なデータ）問題:
特定のカテゴリにしか存在しない項目を全レコードでカラム管理すると、大部分がNULLとなる「スカスカのテーブル」が生まれます。 -
機能拡張のコスト:
顧客から項目追加の要望があるたびにALTER TABLEを実行するのは現実的ではありません。
これらの課題に対し、エンジニアは「どうやって動的なデータを保存するか？」という問いに立ち向かってきました。
2. 2つの保存手法：EAV と JSONB
「スキーマレスなデータをRDBでどう表現するか？」という問いに対する答えとして、歴史的に大きく2つのアプローチがあります。
手法A：EAV（Entity-Attribute-Value）
データを「主体・属性・値」に分解し、縦持ちで保存します。
- 本質: 属性そのものを「データ」として扱う。
- 特徴: メタデータ管理に非常に厳格。反面、複雑なクエリ（JOIN地獄）を招きやすく、型制約が失われやすい。
手法B：JSONB（ドキュメントパターン）
動的なデータをJSONとして1つのカラムに押し込む設計です。
- 本質: スキーマレスな柔軟性を「バイナリ」として保存する。
- 特徴: クエリがシンプルで、アプリケーションの構造体と相性が良い。現代のWeb開発における主流な選択肢。
3. なぜこれらを学ぶのか：メタデータ駆動設計という思想
EAVやJSONBを語る際、多くのエンジニアが「SQLの書き方」に終始してしまいます。しかし、重要なのは「なぜその手法を使うのか？」という目的です。
私たちが目指すのは、メタデータ駆動設計です。
これは、プログラムを「万能なエンジン」として作り、その使い方（構造・バリデーション・表示ルール）をデータベース上のメタデータとして外出しする設計思想です。
- コードを変えずに振る舞いを変える: データベースの「設定」を書き換えるだけで、システムに新しい機能や項目が追加される。
- 開発の抽象化: 個別の業務ロジックを書くのではなく、「定義を解釈して動く汎用エンジン」を作ることに集中できる。
4. この連載で学ぶこと
本シリーズでは、以下のステップで「ノーコードツールや大規模SaaSの裏側」を実装レベルで解き明かしていきます。
- Step 0: 全体像（本記事）
- Step 1: メタデータリポジトリの設計（設定を管理するDB設計）
- Step 2: SQL自動生成エンジンの実装（実行時にクエリを組み立てる）
- Step 3: Server-Driven UIの構築（メタデータからUIを動的に生成する）
- Step 4: 動的データの集計とパフォーマンス（GINインデックスと集計戦略）
- Step 5: バリデーションと権限の外部化（メタデータによる動的制約）
「コードを一行も書かずに新機能が増える」という魔法のような体験を、RDBとメタデータという武器を使って、一緒に実装していきましょう。