テーブルに状態を持たせてはいけない（は本当か） ―― 3 つの設計を見比べる

退会フラグ、公開ステータス、論理削除フラグ —— テーブルに status カラムを置いて UPDATE で上書きする設計は、最も手軽で広く使われている選択肢です。 ただし経緯（履歴）が業務上の意味を持つ場面では、上書きで事実が消え、 後から「いつ・なぜそうなったか」に答えられなくなります。状態は 事実そのものではなく、事実から導かれた加工情報だからです。

この記事は、状態カラムを上書きする設計（方式 A）に加えて、 出来事を追記するイベント記録（方式 B）と 状態ごとにテーブルを分ける設計（方式 C）を、 同じ操作を流し込んで 3 方式並べて見比べられる教材です。 言いたいのは「状態を持つな」ではなく「状態を唯一の真実にして“事実”を失うな」。 状態を保持すること自体は問題ではなく、上書きで経緯が消えることが問題だ ―― というのが本記事の立ち位置です。

まずは下のデモで、同じ操作を 3 つの設計に同時に流し込んで、 データがどう残る／消えるかを見比べてください。

状態は「事実」ではなく「加工された情報」

「会員が退会した」という出来事は事実です。一方、「現在この会員は退会済みである」という 状態は、その事実から導き出された情報にすぎません。事実は過去を変えられないのと同じく、 更新できません。更新すべきでないものを UPDATE しているところに、ひずみが生まれます。

Clojure の作者 Rich Hickey は講演 “The Value of Values” で、 「事実とは起きた出来事であり、知識はそうした事実を比較・結合して導かれる」と述べています。 同じ考え方は 「年齢を保存せず、生年月日を保存する」という古典的な設計原則にも表れています。

ドメインの言葉に「論理削除」はない

ソフトウェアエンジニアの和田卓人氏は、論理削除という概念は現実の業務には存在しないと指摘しています。 顧客が「論理削除してください」とは言いません。現場で使われるのは 「退会」「公開停止」「キャンセル」といった具体的な出来事の言葉です。

つまり業務で起きているのは「状態の削除」ではなく「新しい出来事の発生」です。 退会は会員データの削除ではなく、「退会した」という事実の追加として捉えるのが自然です。 この「出来事を追加する」という捉え方をそのまま形にできるのが、出来事を INSERT で積む方式 Bです （方式 A は事実を上書きしてしまい、方式 C は行を移すだけでは「退会した」という出来事そのものが残りません）。

履歴（順序）と集合（無順序）のミスマッチ

理論面でも無理があります。リレーショナルモデルのリレーションは集合であり、要素間に順序はありません。 一方、状態の変化には「古い・新しい」という順序が必然的に伴います。 順序を持つ履歴を、順序のない集合の中の 1 カラムへ押し込もうとするところに、本質的なひずみが生じます。

設計1：状態を変える「出来事」を追加する

状態を UPDATE するのではなく、状態を変える出来事をそのつどレコードとして INSERT します（上のデモの方式B）。 イミュータブルデータモデルやイベントソーシングと共通の発想です。

CREATE TABLE member (
  id   INT PRIMARY KEY,
  name VARCHAR(255) NOT NULL
);

CREATE TABLE membership_event (
  id          INT PRIMARY KEY,
  member_id   INT NOT NULL,
  event_type  VARCHAR(50) NOT NULL,   -- join / suspend / reactivate / withdraw
  occurred_at DATETIME NOT NULL,
  FOREIGN KEY (member_id) REFERENCES member(id)
);

• 過去の経緯が失われないので、監査・トラブル対応に強い
• 新しい状態が増えても event_type の値を足すだけ。スキーマ変更が不要
• 上書きが発生しないので、データの食い違いが起こらない
• 最新状態を求めるたびに並べ替え・絞り込みが要る。データ量が増えると負荷になりうる

設計2：状態ごとにテーブルを分ける

よりリレーショナルらしい選択肢が、状態そのものをテーブルで分ける設計です（デモの方式C）。 そーだい氏が「ユーザ情報を保存する時のテーブル設計」などで紹介しています。 「どのテーブルに居るか」で状態を表すため、status カラムも絞り込みも要りません。

CREATE TABLE member (            -- 不変の情報。INSERT のみ
  id   INT PRIMARY KEY,
  name VARCHAR(255) NOT NULL
);

CREATE TABLE member_active (     -- 有効な会員はここに居る
  member_id    INT PRIMARY KEY,
  activated_at DATETIME NOT NULL,
  FOREIGN KEY (member_id) REFERENCES member(id)
);

CREATE TABLE member_withdrawn (  -- 退会したらここへ移す
  member_id    INT PRIMARY KEY,
  withdrawn_at DATETIME NOT NULL,
  FOREIGN KEY (member_id) REFERENCES member(id)
);

• 有効な会員は WHERE status = 'active' ではなく member_active を見るだけ
• 仮登録などが増えても member_tmp を足すだけ。既存スキーマは変えない
• NULL になりがちなカラムや UPDATE が必要な行は、そこに状態が隠れているサイン
• 移動だけでは遷移の履歴が残らない。経緯が要るならイベント記録を併用する
• 「1 人はいずれか 1 テーブルにのみ」という排他性はアプリ側で担保する

「イベントソーシングの一言で済む」のか？

この設計を紹介すると、しばしば「それはイベントソーシングと呼ぶもので、その一言で済む話だ」という指摘を受けます。 半分は当たっています。出来事を INSERT で追記し、現在の状態をそこから導出する方式 B の核は、 たしかにイベントソーシングの中心的なアイデアそのものだからです。

ただし「イベントソーシング」という名前のついたアーキテクチャは、もっと重い含意を背負っています。 イベントの列が唯一の正であり、現在の状態は永続化せず全イベントの再生（リプレイ）で都度組み立てるのが基本で、 実務では CQRS・スナップショット・結果整合性とセットで語られます。 イベントのスキーマ変更（バージョニング）、過去イベントの移行、リプレイ性能といった運用コストもそのまま付いてきます。

一方この記事が言っているのは、もっと軽くて広い原則 —— 「事実を上書きせず、出来事を追記する」だけです。 これは川島義隆氏のイミュータブルデータモデルに近く、イベントソーシングとは明確に別物です。 イミュータブルデータモデルは、現在の状態を普通のテーブルとして残し、SQL で素直に引けるようにしたうえで、 リソース（変わらない実体）とイベント（起きた事実）を分けて記録する設計の規律であって、 「イベントログだけを正にして全リプレイで状態を作る」という重い前提を取りません。

さらに、方式 C（状態テーブル分割）に至ってはイベントソーシングですらありません。 行の「居場所」で状態を表す、純粋にリレーショナルな正規化のテクニックです。 「年齢ではなく生年月日を保存する」「事実と知識を区別する」という話も、 イベントソーシングより一段抽象度の高い、データモデリング全般の原則です。

実は Event Sourcing を提唱した Martin Fowler 自身、原典で 「多くのアプリでは最新状態が要求されることが多く、その場合は現在の状態をそのまま保存するほうが、より高速な代替案になる。Event Sourcing ならではの機能が必要になれば、その上に追加で構築すればよい」と述べています。 状態保持＋イベントログのハイブリッドは、Fowler 自身が中立に提示する有力な選択肢の一つです。 「状態カラムを持つこと」と「履歴を残すこと」は排他ではありません。

実装の選択肢を整理すると、現実的には次のあたりに落ち着きます。

• 状態カラム ＋ 監査ログテーブル（最も一般的）
• 状態テーブル分割
• イベントテーブル ＋ スナップショット
• アプリ DB は状態を持ち、分析基盤側で SCD Type 2 として履歴化

どれにもトレードオフがあります。「状態を履歴から導出」する方式は最新状態の SELECT が複雑になりがちですし、 「状態テーブル分割」は親テーブルが肥大化しやすく、複数の状態テーブルに同時に存在しない排他性をアプリ側で担保する必要があります。 複雑さはどちらの方向にも生じうるもので、「状態カラムを持つこと自体が悪」というほどの話ではありません。

つまり「イベントソーシングの一言で済む」とまとめてしまうと、 素の SQL でできる安価な設計の規律と、イベントストアやリプレイを抱える重いアーキテクチャを混同させ、 必要もないのに大掛かりなインフラへ人を押しやるミスリードになりかねません。 ここで言いたいのは「状態カラムを上書きするな」という一段上の原則で、 イベントソーシングはそれを実現する選択肢のひとつにすぎない、というのが正確なところです。

現実的な境界線 ―― 「常に残せ」は理想論

ここまでを「では何でもイベントで残すべきだ」と受け取ると、それは理想論になりがちです。 変更履歴は、残せるなら残したいに決まっています。問われるのはそのコストに現実が見合うか。 会員数（データ量）・更新頻度・保持期間を数字で見積もったうえで、どこまで残すかを ケースバイケースで決めるしかありません。

おおまかな当たりは次の 2 つの問いで付けられます。ただしこれは出発点で、最後は規模の見積もりがものを言います。

体育館の例がわかりやすい縮図です。入退室という事実は課金の根拠なので、上書きや削除は許されません。 一方「今何人いて、満員か」は高頻度に問われるので、毎回イベントを数え直すより 在館数のカウンタを持つほうが実務的です。ただしそのカウンタは「唯一の真実」ではなく、 入退室イベントから導出した投影にすぎない ―― この役割分担さえ崩さなければ、状態を持つことは何も悪くありません。

さらに会員数が増え、更新が頻繁になり、保持期間が長くなるほど、イベントを全件抱える負荷は効いてきます。 スナップショット（ある時点の状態を保存し、以降の差分だけ追う）、古いイベントのアーカイブ、集計テーブルの併用 ―― このあたりを規模に応じて足し引きするのが現実の設計です。

Microsoft Azure Architecture Center も、スナップショットを「イベントストリームの代替ではなく最適化」と位置づけ、 N イベントごとに状態を保存し、読み込み時はそこからリプレイする方式を紹介しています。 同じ資料は 「ほとんどのシステム、あるいはその大部分には、従来のデータ管理で十分」とも明記しており、 Event Sourcing は全方位に推奨される銀の弾丸ではありません。

そしてすべてのテーブルを機械的にこの形にする必要もありません。 履歴が業務上の意味を持つドメイン（契約・申込・承認・金銭授受など）でこの設計が活きます。 UI 設定値や表示順のように履歴を業務的に問わない属性、監査要件のない小規模 PJ では、 状態カラムを素直に UPDATE するほうがコスト・可読性で勝ちます。

まとめ：状態は悪ではない、唯一の真実にするのが悪

保存すべきは加工された状態ではなく、それを生み出した出来事という事実です。 経緯が業務上の意味を持つドメイン（契約・申込・承認・金銭授受など）では、状態カラムを上書きで潰す前に、 その出来事を別テーブルに記録して事実を失わない設計を選びます。

状態によってデータのライフサイクルや属性が大きく変わるなら、状態ごとにテーブルを分け、 高頻度に現在値が要るならイベント＋導出カウンタ（ハイブリッド）でも構いません。 逆に履歴を業務的に問わない属性や、監査要件のない小規模案件では、状態カラムを素直に UPDATE する設計のほうが コスト・可読性で勝ります。あらゆるケースに効く単一の正解はほぼ存在しません。

つまり、言いたいのは 「状態を持つな」ではなく「状態を唯一の真実にして、その背後の事実を失うな」。 状態を保持すること自体は問題ではなく、状態を上書きで潰して経緯が消えることが問題なのです。