DB設計と管理画面設計の基本原則メモ - なぜその原則が必要か？

■ DB設計の3原則：具体例で理解する

1. シンプル性を保つ

なぜ必要か？

複雑な設計は保守性を下げ、バグの温床となる。また、チームでの共有が困難になり、新メンバーの学習コストが増大する。

❌ よくある間違い例

1. 過剰な正規化
users
└── user_details
    └── user_additional_info
        └── user_settings

2. 意味不明な命名
t_1
├── cl_01
└── cl_02

3. 1つのテーブルに全部詰め込む
products
- id
- name
- price
- category
- stock
- supplier_name
- supplier_address
- supplier_phone
- order_history
- sales_data

✅ 正しい例

1. 適切な粒度の分割
users
├── user_profiles
└── user_settings

2. 明確な命名
users
├── columns
  - id
  - email
  - password_hash

3. 責務の分離
products
├── product_details
└── supplier_info

2. 拡張性を確保

なぜ必要か？

システムは必ず変更・拡張が発生する。後からの変更が困難な設計は、開発速度を低下させコストを増大させる。

❌ よくある間違い例

1. ハードコーディング
user_type
- 1: 一般
- 2: 管理者
（新しい種類を追加できない）

2. 固定長の制限
phone_number VARCHAR(11)
（国際電話番号に対応できない）

3. 拡張を考えない設計
order_status
- 'completed'
- 'canceled'
（中間状態を追加できない）

✅ 正しい例

1. マスタテーブルによる管理
user_types
- id
- name
- description

2. 余裕を持った設定
phone_number VARCHAR(20)

3. 状態遷移を考慮した設計
order_statuses
- id
- name
- next_possible_statuses

3. 安全性を担保

なぜ必要か？

データの損失や不整合は、ビジネスに致命的な影響を与える。セキュリティ事故は信用問題に直結する。

❌ よくある間違い例

1. 制約の未設定
users
- email (制約なし)
- phone (制約なし)

2. 物理削除
DELETE FROM users WHERE id = 1

3. パスワードの平文保存
users
- password VARCHAR(50)

✅ 正しい例

1. 適切な制約
users
- email UNIQUE NOT NULL
- phone VARCHAR(20) CHECK (phone ~ '^[0-9\-\+]+$')

2. 論理削除
users
- deleted_at TIMESTAMP
- deleted_by INT

3. セキュアな設計
users
- password_hash CHAR(60)
- last_password_change TIMESTAMP

■ 管理画面設計の3原則：具体例で理解する

1. 安全性を最優先

なぜ必要か？

管理画面でのミスは影響が大きく、復旧が困難なケースが多い。特に深夜や緊急時は、ミスのリスクが高まる。

❌ よくある間違い例

1. 危険な操作が容易すぎる
[全ユーザー削除] ボタンを直接配置

2. 影響範囲が不明確
「設定を変更しますか？」
[OK] [キャンセル]

3. 復旧手段なし
データ削除後の
「元に戻せません」

✅ 正しい例

1. 多段階の確認
[削除実行] 
→ 対象の確認 
→ 理由の入力 
→ パスワード再入力

2. 影響範囲の明示
「この操作により100件のデータが
  変更されます：
  - ユーザーデータ: 50件
  - 関連注文: 50件」

3. 復旧オプション
「この操作は30日間取り消せます」
[実行] [キャンセル]

2. 分かりやすさを重視

なぜ必要か？

操作の迷いやすさは、ミスや遅延の原因となる。特に緊急時や新人が操作する場合にクリティカル。

❌ よくある間違い例

1. 不親切な操作導線
[実行] ボタンのみ

2. 分かりにくいエラー
「Error Code: 1452
参照整合性制約違反」

3. ヘルプが不十分
「マニュアルを参照してください」

✅ 正しい例

1. 明確な操作ステップ
1. 対象選択
2. 内容確認
3. 実行確認
4. 完了確認

2. 具体的なエラーガイド
「このユーザーは現在注文処理中の
ため削除できません。
対処方法：
1. 注文をキャンセルまたは完了
2. その後再度削除を実行」

3. コンテキストヘルプ
各項目の横に[?]ボタンを配置
クリックで説明表示

3. 記録を確実に

なぜ必要か？

問題発生時の原因特定や、監査対応に必須。また、操作の証跡として重要。

❌ よくある間違い例

1. 不十分なログ
「データ更新」

2. 変更内容が不明確
「設定変更」

3. ログの確認が困難
開発者用コンソールのみ

✅ 正しい例

1. 詳細なログ
2024-01-01 13:45:23
user: admin
action: user_delete
target_id: 123
reason: 不正アクセス検知
ip: 192.168.1.1

2. 変更内容の記録
before: {status: active}
after: {status: suspended}
reason: 規約違反
evidence: ticket#1234

3. ログの可視化
管理画面から
- 操作ログ検索
- 変更履歴の確認
- 監査レポート出力