DBのカラムの話とか

外部テーブル、enum、varcharとかにコメントをいただいたので続き。

なんかだいぶ後付けなんですけどね、参考程度。

結局、CBC（ケースバイケース）な訳ですが、ここ２年ばかり、「初期開発時には最低限の機能だけで、要求の殆どは運用中に発現する」といった開発ばかりやっているからかもしれないです。

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

まぁそういった初期開発よりむしろメンテナンスな開発体制だからかもしれませんが、

2のenumについてですが、status が増えた場合、カラムの改修が入るというのが最大のネックかな、と。
例えば、オープンソースとか配布されたものを考えると、
元々enum を採用しており、その後、新バージョンで status が追加された場合、
データベースのカラム変更を伴うアップデートスクリプトが必要となるわけです。

まぁオープンソースの例は極端な気がしますが、
個人的にはカラム変更ってあまりやりたくなかったりします。
既存データを破損させる可能性が高いから。
あらかじめ検証済みの alter の SQL文を使えば問題はないのですが、そういう手間暇を生んでしまうのがメンドウだったりします。

1 のマスタですが、個人的には正しいのはこれかなという気もします。

ただし、IDがなんとなく意味を持っちゃうとどうだろうか。

"sleep" => "ready" => "running"

というようになんらかの状態遷移を持っており、

1 sleep
2 ready
3 runnning

とIDが設定されているとして、そこに "wakeup" を追加したとして、

"sleep" => "wakeup" => "ready" => "running"

と状態遷移が変わったとしても、

1 sleep
2 ready
3 runnning
4 wakeup

とせざるを得ないのはなんだか気持が悪い気がします。

1 sleep
2 ready
3 wakeup
4 runnning

こういうふうにマスタを変更し、status を所有するテーブルの値も変える？
って運用中のサービスであれば停止する必要があるし、停止させる為の手間暇（関係者各位やユーザへの告知）が一苦労。

そもそもプログラム中でマスタstatusをどの程度必要とするか？という話もあったりするので。
キーしか必要としないものであれば、多分いらないだろうし。

で、文字列をキーとして用いてしまう件ですが、
数字の 2 を 3 と打ち間違えるのと、"sleep" を "slep" と打ち間違えるのにどの程度の差があるか？
プログラム中でそれらの打ち間違えを防止する為に alias などを使用するのであれば、
結局、数字も文字列もあまり変わらないのかな。
であれば、より直感的に理解できるほうがいいのかな、と。

とはいうものの、CBCですからね、所詮。
こういった状況がむしろ例外かもしれないですし。
一人開発プロジェクトが多いからかな、ってのもあります。

そもそも「最低限の要求定義」という状態自体が間違いなのかもしれません。
が、間違いを間違いと指摘したところでどうにもならないし、むしろ「頑張って作った機能が使われない虚しさ」を感じることが多いから、なるべき初期は軽めにただし変更しやすくってことになるのかな、とか。
要求定義の精度が上がれば使われない機能も減るのか？
おそらく業務系かコンシューマ系か？で「何が必要で何が不要か？」の精度は分かれるのではないかと思います。
例えば、ニコニコ動画システムの要求定義は当初はニコニコ市場の登場を見越せてないと思います。
でも、後から必要になったと分かったのであれば、それはそれで対応しなくては仕方がないだろうし。

とはいうものの、いわゆる正規化とかは真面目にやったほうがいいかな、とは思いますが。
文字列ってのは邪道なんだよね、やっぱり。