• 追加された行はこの色です。
• 削除された行はこの色です。
• こうしておけばよかった/設計/マスターデータをenumでもつ へ行く。
• こうしておけばよかった/設計/マスターデータをenumでもつ の差分を削除

#author("2018-08-31T02:30:35+00:00","default:haruki","haruki")
* キーワード [#ne8e414f]
- マスタデータ
- enum
- DB、データベース

* 何か [#m679f08e]

マスタデータをenumでもつ。

* なぜか [#ubb8dcaf]

マスタデータはDBにあるもという頭で実装を進めてしまった。しかし、選択肢によって異なる振る舞いをさせたい場面がでてきた。マスタデータごとに振る舞いの違いをDBの列に追加するのは手間であったので、この場合はenumのオブジェクトに変換してやることにした。

その結果、管理が二重になった。単に選択肢があるだけのものはDBだけにあり、振る舞いをもつものはDBとenumにあるという状態。マスタデータの追加・変更で抜けが起こるのは時間の問題だと思える。

また、enumを得るのにDBからいちどレコードを引かねばならないことになってしまった。これはコードの見通しを悪くするし、テストコードの作成をやりにくくさせる結果になった。

さらに、DBにレコード追加すれば選択肢を増やせるというありがちなメリットは、結局活かせていない。ビジネスサイドがそれをできるのでなければ、むしろアプリを変更してビルド・デプロイかける方がよっぽど楽で安心感のある作業である。

* どのように [#c897ffbd]

マスタデータはenumにもたせることを基本にする。

DBにもたせるマスタデータをどうかんがえるか。ビジネスサイドが画面などを通して変更したい都合があるときだけでよい。画面に見せて画面から変更できるものなので、DBに永続化させる対象として違和感はない。

* 反省 [#j6d56d0f]

ユースケースをよく考えなければならなかった。たしかに、DBのレコードを追加すれば選択肢を増やせはするが、それはenumの一行を足すのと変わらない。むしろ、振る舞いをもつような業務的に意味のある項目であるならば、コードとして表現されている方が好ましかった。

//* 関連 
//- 
//- 

//* 参考 
//- 
//-