Q&A
データベースに入れなければいいのでは？
HTML を作っているのは Java ですよね？
Web画面上の選択肢（ラジオボタンなど）の表示内容や、プログラム内で判断する値を以下のようなコードテーブルを使って管理しようと考えていますが、
コードとテーブルの2重管理になるのではないか？
ということに悩んでいます。
| グループ | コード | 値 | 説明 |
|---|---|---|---|
| 001 | 0 | 男性 | 性別 |
| 001 | 1 | 女性 | 性別 |
| 002 | 0 | xxx | ステータス |
| 002 | 1 | yyy | ステータス |
| 002 | 2 | zzz | ステータス |
グループ='002'の選択肢を追加したい場合は、レコードを追加すると画面にも自動的に反映されますが、
プログラム内で分岐に使おうとすると定数やenumで定義することになるので、結局二重管理になるのではないかと思えてきました。
■知りたいこと
2重管理にならないようなうまいやり方があれば教えてほしいです。
enumや定数定義をしなくても判断に使えるような方法があるのでしょうか？
9/30追記
コードテーブルで定義しながら、アプリで判断が必要な場合はプログラムで判断が必要で、それって両方で2重管理になるので意味がないのでは…と思い、
１．コードテーブルってどんな時に起用すべきでは？
⇒制御がいらないものに限定すべきでは？
不変のものは定数にすべきでは？
２．もしかしたら自分が知らないうまいやり方があるのでは？
ということが知りたいと思い質問しました。
コードテーブルはだれが利用するのでしょうか。
（個人的にはenumを簡単にメンテする為の中間テーブルとしては有りだと思いますが）
システム管理者を想定しています。
コードテーブル追加だけで画面上の選択肢を追加できると思っていたのですが、制御が必要な場合はプログラムで判断しなきゃ、、あれれ…と思った次第です。
失礼しました。ここでいう「だれ」というのは動的なHTML生成の為にサーブレットで使うとか、ビジネスロジックやバリデートで使うという意味です。
画面上の選択肢生成に使えるのはもちろん、コード値の範囲、妥当性チェックには使えなくもないです。
しかしそもそも大きくビジネスロジックが分岐するのものには、Enumクラスなどがあった方がやりやすいでしょう。
一方で、画面の選択肢を増やすのにEnumクラスは必要ありません。
つまり、コードの性質によって二重というより両方必要なものと片方で良いものがあるということです。
それらを一つのコードテーブルでごっちゃにすべきではないかと思います。
あるいは片方に寄せるというのも設計の1つですが、単純な画面上の選択肢を増やすのとビジネスロジックを実装するのと話が別なのです。
マスタテーブル使ってシステム作ってるとよくあるやつですね。
正解はわかりませんが私は最近は「特殊な処理が発生する分岐があるコード値のみ定数宣言」にしています。
S_kawaさん
必要な場面（画面、バリデート）で使おうと考えていました。
上のテーブル例には書いていませんでしたが、表示順序もコードテーブルで管理しようと考えていました。
q_sane_qさん
どちらか一方にすべきと凝り固まってたようです。
もやもやが晴れました。
ありがとうございます。
回答2件
0
ベストアンサー
質問へのコメントにも書きましたが私の今の主なやり方は「特殊な処理が発生する分岐があるコード値のみ定数宣言」です
ですがこれが正解と言い切れるわけではないのでこれまでのやり方の変遷も書いてみます
最初の頃は、マスタのコードによって固有の処理を噛ませることを考え、マスタのコードと同じ定数をすべて宣言していました。
もちろん質問者様と同じく（と思いますが）、
if(code == 3)｛｝
などと数字をベタ書きしたくなかったからです
で、これはすぐにenum使用に変わりました。
DBを残した理由は、当時の私の開発においては、全てのコードに固有の処理があったわけでは無かったからです。
つまり固有の処理がないなら、ユーザからのマスタ追加の要望に速やかに反応できるようDBへの追加だけで住ませ、enumへの追加は別の更新時に巻き取ろうという考えです
ただこんな運用をしているとどこかで忘れたままになりDBとenumとの差異が出て来るので、今度はDBとenumを比較して差異を表示する機能を作ったりもしました。
しかしながら、そんな機能を作るのがまた面倒で仕方なくなり、最初に書いた
「特殊な処理が発生する分岐があるコード値のみ定数宣言」
に変わりました。
固有な処理がない場合はソースコードをいじらなくていことの他に、
「この定数群にコード値がなかったら特別な処理がない」
というシンボルにもなるので今はこれがいいかなと思いそうしています。
また別パターンとして、「コードで処理を分岐させたいけどそれは数パターンのどれかに分けられる」場合には、マスタテーブルにどの分岐か示すカラムを1つ追加したりもしたことがあります。
ちなみに本題とは関係ないのですが、質問内容を見て真っ先に思ったというか気になったことはテーブルがOTLTになっていることでした
「OTLT」で検索すると出てくると思いますが、ややグレーゾーンなテーブル設計だと思います…（好きな人も多そうですが）
投稿2019/09/30 03:32
総合スコア610
OTLTというキーワードだったんですね。まさにその通りです。
今までの経験上、こういう形のテーブルを採用している現場が多かったので、モヤモヤしながら使っていました。
助かりました！ありがとうございます！
あれ、もしかして私もちょっと内容を取り違えていましたでしょうか
上の回答は「コード」レベルでの切り分けの話で
本題が「グループ」レベルでの切り分けの話であれば「OTLTをやめる（まだやめられる段階であれば）」ですね
実は結構いろいろなところで見るのですが厄介を持ち込むことがあるので個人的には極力使用を控えたい設計です
0
値や説明？は変わることがあるという観点から別テーブルにしてjoinさせてはいかがでしょうか。
「説明」にあたる部分は「区分」のようなものなのでそれはそれで管理するテーブルが必要そうですが。
必要なデータ一通り洗い出してどう使うのかもきちんと整理した上で正規化していってください。
投稿2019/09/27 07:13
総合スコア80875
DB内のレコードとして持つコードと、プログラム内の定数として持つコードで2重管理になるという質問だと思うので、テーブル設計を正規化しても問題は解決しないのではないでしょうか？
勘違いしたかもしれません。
「どっちかだけにしたらいいのでは？」くらいで良かったかな点
説明が不明瞭だったかもしれません。
コードテーブルで管理しても、結局定数作らないといけないんじゃないのかと思ってこんな質問しました。
enumで管理しようと傾いています。
説明が不明瞭というより考えてることが意味不明です。定数を使うならデータベースは使えないし、データベースを使うなら定数は使えません。値が動的に変わらないから定数と言うのです。
パフォーマンスを考えるなら動的管理を捨てて定数を使うべきだし、動的管理を考えるならパフォーマンスを捨ててデータベースを使わなければいけません。
データベースをいくら変更しても定数は変更できないので、二重管理などできません。管理とは別にデータベースを無意味に変更するだけです。
そのあたりまとめて整理して質問本文に反映してもらいたいですね
あなたの回答
tips
プレビュー
