formのvalue値を文字列ではなく、数値でデータベースに保存するメリットとは？

下記のような選択フォームがあり、ユーザーの選択値をDBに保存する際に、
文字列ではなく数値で保存するのをよく見かけますが、
これにはDBの容量節約以外にどのようなメリットがあるのでしょうか？

PHP
1// 定数管理ファイル
2define('OPTION_LIST', array(
3	1 => "初級",
4	2 => "中級",
5	3 => "上級",
6));

PHP
1// View（例ではbladeを使用しています）
2<select name="level">
3	@foreach (Config::get('const.OPTION_LIST') as $key => $val)
4	<option value="{{ $key }}">{{ $val }}</option>
5	@endforeach
6</select>

DBに数値で保存しているデメリットとして、
下記のような処理が毎回必要になるのですが、
これは一般的なことでしょうか？

・選択値を表示する場合に、数値から文字列に置き換える
・「初級」で絞りこむようなSQLを書く際に、「WHERE = 1」ではわかりにくいので、
「WHERE = OPTION_BEGINNER」のように各オプションにも名前を付ける

素人考えかもしれませんが、
それなら最初から、DBに「初級」として保存しておいたほうがいいのでは？と思い質問させていただきました。

メリット・デメリットなどご回答いただけますと幸いです。

行動規範の内容に同意します

回答5件

数値のメリット

見た目上のブレが少ない

似たような文字との混同例えば「l」と「1」や「0」と「O」などを始め、
文字列は見た目がならずしも認識と正しいとは言えない

インデックスがききやすい
オートインクリメント処理ができる
拡張しやすい
範囲が取りやすい（不等号やbetween）
文字列な意味があるのであとから変更される可能性がある

総じてSQLとしてのデータ管理がしやすいということ。
逆にデータ効率が良い分、人が見てわかりにくくなっていくので
それに対応するのがマスターテーブルを使った正規化

投稿2018/11/01 01:49

yambejp

総合スコア114779

sazi

2018/11/01 02:13

>インデックスがききやすい同じバリエーションなら、インデックスが採択される可能性は同じなので、高速という表現の方が良いのでは？

stack-overflow

2018/11/01 02:20

回答ありがとうございます！思ったよりたくさんのメリットがあるのですね。勉強になります。 >逆にデータ効率が良い分、人が見てわかりにくくなっていくので >それに対応するのがマスターテーブルを使った正規化マスターテーブルに関してですが、「性別」「役職」「都道府県」...のような選択フォームが1つのアプリで30個や50個ほどある場合でも、各選択肢ごとに1テーブル用意していく、つまり「性別マスターテーブル」「役職マスターテーブル」..のようなイメージでしょうか？

yambejp

2018/11/01 03:23

都道府県:マスターとしては定番性別:男女だけでなく「選択しない」や「その他」などの選択肢が必要役職:微妙・・・ある程度定型化されている役職だけならよいですが組織改編で役職名はコロコロかわるのでむしろ自由入力の方がよいと思います。（等級の管理は別途する）また簡易なデータ管理として、ENUM型やSET型でも同様の効果が得られますがその場合マスタを参照して一覧を得ることができませんのでご注意ください

行動規範の内容に同意します

ベストアンサー

例に挙げられているデメリットは、本来は「選択肢マスタ」があれば解決するものです。
※データ上の値と、表示上の文字列を分けて管理する

データの論理的な「意味」と、表示上の「文字列」とを分離した方が、後々都合がよいことが多いのです。
例えば「初級」という意味はそのままで、表示は「ビギナー」に変えたいと思っても、意味と文字列が一致していると、修正箇所が多くなって面倒になります。表示文字列を分離していれば、単にそこの設定を変えるだけでいいのですから。

投稿2018/11/01 02:02

tacsheaven

総合スコア13703

stack-overflow

2018/11/01 02:26

回答ありがとうございます！他の回答者様にもコメントしたのですが、下記アドバイスいただけますと幸いです。「選択肢マスタ」に関してですが、「性別」「役職」「都道府県」...のような選択フォームが1つのアプリで30個や50個ほどある場合でも、各選択肢ごとに1テーブル用意していく、つまり「性別マスターテーブル」「役職マスターテーブル」..のようなイメージでしょうか？

tacsheaven

2018/11/03 05:01

いえ、そういう場合は「種別」かなにかカラムを追加して、まとめるでしょうね。 ※都道府県の場合は別にするかも知れませんが

stack-overflow

2018/11/05 03:41

再度回答ありがとうございます！作成予定のWebアプリでは選択フォームがたくさんあるので、アドバイス頂いた方法で構築して行こうと思います。勉強になりました！

行動規範の内容に同意します

上で回答されている通りですが…

例えば、仕様変更で文言が変わった場合を考えると
影響範囲が限定的になるって話もありますね。
あと、英語化する場合とか。

投稿2018/11/01 02:09

takasima20

総合スコア7458

stack-overflow

2018/11/01 03:41

回答ありがとうございます！皆さん数値のほうがいいという意見でしたので、数値での保存を採用させていただきます。

行動規範の内容に同意します

初級、中級、上級といった文字で情報を持つと、級の名称が変わったとか、級が増えたり、他の言語に移行するとプログラム・コードを変更が必要になったりと保守性・移植性が劣ります。
数値 → 顧客ID とすると、企業合併、結婚や養子縁組などにより顧客名が変わった時、顧客マスタの顧客名を変更するだけで済みます。

投稿2018/11/01 02:08