DBに入れる文字列が決まってるケースの場合に、enumはほとんど使わない

外部テーブル、enum、varcharとか | 眠る開発屋blog

例えば、あるテーブルで状態(status)を扱うとして、”sleep”、”runnning”、”ready”の３つの状態をがある場合、以下の３パターンが考えられる。

1. 外部テーブルとして マスタstatus を準備し、元のテーブルにはキーのみを持たせる。
2. enum型のフィールドを作成し、 値を”sleep”、”runnning”、”ready” とする。
3. varchar(30)とかにしておき、文字列をそのまま入れるようにする。

この中から選べって言われたら、
「ユーザーが自分でステータスを変えたい」って言われたら1で、そうでもなければ3かな。

でも、3はそういう感じではなくて、int型とかにしておいてアプリケーションの方でステータス定義をする。PHPなら

<?php
define('HOGE_STATUS_SLEEP', 1);
define('HOGE_STATUS_RUNNING', 2);
define('HOGE_STATUS_READY', 3);

とか。やっぱ文字列は不安定だし。enumってあまりつかわないなー。アプリ側で定義した方が色々と柔軟な運用ができる気がします。

で、結局はDBのカラムの話とか | 眠る開発屋blogのコメント

やはり、「自分の土俵」がどこにあるかで「どこでリスク回避するか」の考え方が変わりますね。

だと思う。

VB屋さんと連携をする話をしてて、それは自分がWebアプリでデータ収集をしてそのデータをFTPでVisualBasicに取り込んでパースして・・・って案件なんだけど、その時にWeb側で

1. 半角→全角に変換しておいてくれ
2. 電話番号のハイフンをとっておいてくれ
3. 姓名の全角スペース、半角スペースを気を付けてくれ

とか言われて、「はぁ、そんなのそっちでやれよ」って思ったことがある（全然別の人から2回)。

こっちでやるのは簡単だけど、それやっちゃうと「本当にユーザーが入力した元のデータがなんなのか？」っていうのがわからなくなる可能性があるよな。それは良くないと思うんだ。これも、悪い意味で「どこでリスク回避するか」が出ちゃってる面だと思う。