どの選択肢をDBで管理するか
DBで管理する
DBを用意する必要がある
インフラの用意はもちろん、スキーマ設計も別途必要になる
DBを更新するだけでデータの追加削除ができる
deployが不要
変更頻度が高い場合は有用
その選択肢を他のプロジェクトでも共有できる
DBにアクセスする時間がかかる
selectboxの選択肢を表示するためにいちいちアクセスしないといけないとか
表記揺れが起きづらくなる
table Aで使った値を、table Bでも使用する場合に、参照できるため、表記ゆれが起きない
例えば、
東京と東京都のような揺れ
2022/1/1 01:01:01と2022-01-01 1:1:1のような揺れ
コードベース内で管理する
Domain Modelとして定義できるため、validationをより厳格にしやすい
型定義の時点でDBに勝っているし、
コードも使えば更に厳格になる
選択肢を列挙しても問題ないぐらいの数なのであればこちらで良さそうmrsekut.icon
選択肢の表示に外部アクセスが不要
インフラの用意やスキーマ設計に時間をかけなくて良い
変更のたびにdeployが必要
変更時に気をかけなければ表記ゆれが容易に起こる
今考えてるのって、
Viewで選択肢をいくつか選んで、それをDBに登録する、というもの
例えばカスタマイズできるPCを注文する時に
CPUの選択肢: C1, C2, C3
メモリの選択肢: M1, M2, M3
筐体の選択肢: B1, B2, B3
のようなものをViewで提示して
ユーザーが(CPU:C1 メモリ:M3, 筐体:B2)のように選択して
この注文データ(CPU:C1 メモリ:M3, 筐体:B2)をDB(order table)に登録することになる
この時、C1, C2, C3のような選択肢をDBで管理するか？という話をしている
ここでは選択肢が3つ程度なので、どちらでも良さそうな感じがある
この「どちらでも良さそう」という状況を考えている
ここで、order tableの内容を考えると
選択肢をDBで管理した場合
C1, C2, C3というrecordを持つcpu tableを定義することになる
order table内のCPU:C1のC1の箇所は、cpu tableに外部キーを作ることができる
そのため、表記ゆれは起きないし、order table側に制約をかけられる
存在しないC4などの値を誤って入れることがない
どこか別の場所からorder tableを編集する際も安心安全
選択肢をコードベース内で管理した場合
order table内のCPU:C1のC1の箇所は、ただのstringになる
ここに制約はかけられない
別の場所からorder tableを編集することはないと規定しないと怖い
各recordに相当するものを型として定義したい場合は、どちらかに統一したほうがいい
その項目を変えた時に、DBも変えないといけないし、型も変えないといけない