PostgreSQL Strategy

本記事の前提となる Craft ERP（生成AI × 仕様駆動開発による小売業向け基幹業務システムの開発プロジェクト）の概要・目的・技術選定方針は Craft ERP Overview にまとめています。

1. 設計思想（前提）

• 整合性を「維持しやすい」構造を最優先する — UI の使いやすさより、テーブル設計が先。
• 結果だけを記録しない — 「現在値」を上書きする設計は根拠を説明できなくなる。取引の根拠データを縦に積み、現在値は集計で導く。
• ID 中心設計 — 業務コード（バーコード等）を主キーにしない。内部 ID と業務コードを分離する。
• シンプルさ優先 — 過度な正規化・抽象化・分散を避け、人間と AI が理解しやすい構造にする。

2. 正規化方針

• 基本は正規化（第3正規形を目安）し、マスタと取引を明確に分ける。
• 参照整合性は外部キーで担保する。
• 表示・性能のための非正規化（サマリー等）は、正本（縦持ちの取引データ）を保ったうえで派生として持つ。非正規化を正本にしない。

3. ID 中心設計

• 主要エンティティに業務的意味を持たないサロゲートキー（内部 ID）を持たせる。
• 商品コード・JAN/バーコード・店舗コードなどの業務コードは属性として持つ（主キーにしない）。
• これにより、コードの変更・統廃合・重複・体系変更に、参照を壊さず追従できる。

4. 集計設計（SUM 中心）

Craft ERP の集計は、「明細を SUM して現在値・実績を導く」ことを基本とします。

• 売上・在庫・仕入などの「現在値」は、原則として取引明細の合算で求める。
• 例: 在庫数 = 入庫合計 − 出庫合計。売上実績 = 売上明細の SUM。
• 「現在値カラムを直接 UPDATE する」設計は避ける（更新漏れ・競合・整合性崩れ・根拠喪失の温床）。
• SUM が重くなる場合はサマリーテーブルを派生として用意する（第7章）。

5. 売上管理

• 売上はヘッダ（取引）+ 明細（商品単位）で持つ。
• 明細に単価・数量・税区分を保持し、合計は SUM で導く（合計カラムは派生・キャッシュ扱い）。
• 取消・返品は元取引を書き換えず、反対仕訳（マイナス明細）として積む。

6. 在庫管理

• 在庫は「現在数量を上書き」ではなく、在庫変動を縦に積む（入庫・出庫・棚卸調整などのイベント）。
• 現在在庫 = 変動の SUM。これにより「なぜこの在庫数なのか」を常に説明できる。
• 棚卸は実数を記録し、差分を調整イベントとして積み、理論在庫と実在庫の乖離も履歴に残す。

7. 履歴管理 / サマリーテーブル

• 取引・変動データは追記中心（イミュータブル寄り）で扱い、更新・削除を最小化する。
• マスタ変更は、必要に応じて有効期間（from/to）や履歴テーブルで追跡する。
• 重い集計には日次・月次サマリーテーブルを派生として持つ。正本（明細）から再生成可能にし、壊れても作り直せる位置づけにする。

8. パーティショニング

• 増加し続けるテーブル（取引・在庫変動）は、将来的に日付（月次等）でのレンジパーティショニングを検討する。
• 導入は「データ量・クエリ特性が見えてから」。初期から過剰に分割しない。

9. バックアップ戦略

• マネージド PostgreSQL（→ Neon vs Supabase）の自動バックアップ + PITR を基本とする。
• 保持期間・費用はサービス・プラン依存のため、採用時に確認する。
• 重要マスタ・設定は、論理バックアップ（dump）の併用も検討する。

10. 将来のデータ増加への備え

• 初期 50GB・年 10GB 増（想定 50〜150GB）を前提に、インデックス設計と集計コストを意識する。
• 増加に効く順で対応する: (1) 適切なインデックス → (2) サマリーテーブル → (3) パーティショニング。
• マルチテナント（複数顧客・多店舗）化に備え、テナント識別（店舗 ID 等）を早期に設計へ織り込む。