Skip to content

DATA_MODEL_RECOMMENDATION.md

Latest commit

 

History

History
87 lines (74 loc) · 3.56 KB

DATA_MODEL_RECOMMENDATION.md

File metadata and controls

87 lines (74 loc) · 3.56 KB
Raw

データモデル方式の実務推奨（結論版）

結論

おすすめは Hybrid（現在値テーブル + イベント履歴テーブル）です。
全テーブルをイミュータブル化する方式は、通常業務では重すぎることが多いため、対象を絞る運用が実務的です。

推奨イメージ

flowchart TD
  A[全イミュータブル] -->|重くなりやすい| B[対象を限定]
  B --> C[Hybridを標準採用]
  C --> D[イベント系のみImmutable強化]
Loading

なぜ Hybrid か

  • 現在値参照が速い（一覧・検索・API応答が軽い）
  • 履歴を保持できる（監査・追跡に対応）
  • 実装と運用のバランスが良い（開発速度を落としにくい）

推奨方針

  • イベント系（状態遷移・承認・入出金・取引）: イミュータブル履歴を採用
  • 属性系（プロフィール・設定・補足情報）: 通常の UPDATE モデルを採用
  • ステータス管理: CHECK ではなく status マスタ + 外部キー

非推奨（原則）

  • 全テーブルをイミュータブルにする
    • 参照クエリが重くなる
    • テーブル肥大化が早い
    • 開発・保守コストが上がる

方式選定の目安

  • 監査要件が強い / 改ざん耐性が必要: Hybrid 以上（必要箇所で Immutable）
  • 参照性能重視・通常業務中心: Mutable + 必要箇所のみ履歴
  • 要件が混在: Hybrid を標準にして対象限定で Immutable を追加

マスタ系とトランザクション系の位置づけ

  • マスタ系テーブル: Mutable を基本にする
    • 例: status_master, currency_master, country_master
  • トランザクション系テーブル: Hybrid を基本にする
    • 例: 申請、承認、入出金、売買、状態遷移
  • 監査要件が特に強いトランザクション: Immutable Event を追加で適用する
flowchart LR
  M[Master Data] --> MM[Mutable]
  T[Transaction Data] --> H[Hybrid]
  H --> I[Immutable Event for audit-critical domain]
Loading

status等を数値直持ちしている場合の扱い

  • status = 1/2/3 のような直値運用は暫定対応として扱う
  • 新規実装では status マスタ + 外部キー参照へ統一する
  • 既存は段階移行を推奨する
    1. status マスタ作成（status_id, status_code, status_name）
    2. 業務テーブルに status_id 追加
    3. 既存の数値列から status_id へデータ移行
    4. アプリ参照を status_id に切替
    5. 旧 status 数値列を廃止

方式別のメリデメ要約

  • Mutable
    • メリット: 軽い、速い、実装が簡単
    • デメリット: 履歴追跡が弱い
  • Immutable Event
    • メリット: 監査と追跡に強い
    • デメリット: 参照が重い、肥大化しやすい
  • Hybrid
    • メリット: 履歴と性能のバランスが最もよい
    • デメリット: 更新時の整合性管理が必要

最小実装テンプレート

  • users（現在値）: created_at, update_at
  • user_status_events（履歴）: created_at のみ（update_at なし）
  • status_master（マスタ）: status 定義を集中管理

実務での採用順（推奨）

  1. まず Hybrid で開始
  2. 性能課題はインデックス・集約で対処
  3. 監査が必要な領域だけ Immutable を強化
  4. 全面 Immutable は監査要件が極めて強い場合のみ検討
flowchart LR
  S1[Start Hybrid] --> S2[Tune Index/Aggregation]
  S2 --> S3[Expand Immutable for audit-critical domain]
  S3 --> S4[Full Immutable only if strict audit demands]
Loading