DBのステータス値を文字列で保存するパターン

1. 目的

• DBのデータを数値ではなく文字列で保存することで、人間が解釈しやすいデータとすることで開発・運用の手間を削減したい

2. 課題

ステータス値を数字で管理すると発生する問題

• DBを直接参照した際、数値が何を示すかソースコードやドキュメントを確認するまで判別できない（マジックナンバー化）
• 数値と意味の対応表（仕様書）の更新コストや更新漏れ発生リスク
• 外部システムやBIツールへデータを渡す際、常に「数値→名称」の変換ロジックを説明・実装する必要が発生

3. 対策

ステータス値を文字列で管理する

• コード値を採用し、status カラムに active, pending, archived といった、短く一意な英単語を格納する
• CHECK制約を活用し、意図しない文字列の混入を防ぐ

4. メリット

可読性向上

• SQLクエリの結果がそのまま意味のある単語として読めるため、デバッグや障害調査の手間が減る

ドキュメントによる説明が不要

• 外部システムや分析ツールがデータを参照した際、追加の説明なしにステータスを正しく解釈可能になる

実装のシンプル化

• フロントエンドやAPIレスポンスにおいて、数値から文字列への変換処理が不要になり、実装がシンプルになる

5. デメリット

ストレージ容量の増加

• 数値型（1〜4バイト程度）に比べ、文字列型はデータ量に応じて数倍〜十数倍のサイズを消費する
• ただし、現在のストレージ容量とコストを考えると微差

インデックス効率の低下

• 大量データを扱う場合、数値比較に比べて文字列比較はCPUやメモリへの負荷が高くなる
• ただし、非常に膨大なデータ（数千万件〜）を扱う場合の話

タイポのリスク

• Check制約を使わないなど実装が不適切である場合、綴りミスがデータに混入し、検索にヒットしなくなる可能性がある
• ただし、これは数値でも同じである

6. 注意事項

原則としてコードの変更は不可とする

• 一度保存した文字列を変更する場合、関連する全レコードの更新が必要になってしまう
• 名称の変更が予想される場合は、表示名（ラベル）だけを別で管理するなどの検討が必要

文字列の長さの配慮

• コードを保存するカラムはVARCHARで定義されることになる
• 将来の長いステータス名を見越して余裕を持って定義しつつ、無意味に長すぎないよう配慮する必要がある
• 大体VARCHAR(20)程度が無難か

大文字・小文字の統一

• DBの設定（照合順序）によって、Active と active が区別されるかどうかが変わる
• 一貫して小文字で保存するなどのルールの徹底が必要