およびデータベース VS 配列データ

Question

お世話になります。初歩的なことかも知れませんが、例えば会員登録などで
性別　男or女
血液型　A・B・O・AB
などを選択してもらい、各データを個人情報として登録する場面があるかと思います。

これまで上記、性別や血液型などは、

sexテーブル
no　name
----------------
1　　　男
2　　　女

のようにテーブルを用意して置き、各名称のID（番号）を、今回の例でいう個人情報テーブルに格納していましたが、血液型テーブルや性別テーブルなどのように、情報の量が少ないのであれば、データベースを用いず、

<?php
sex = array("男", "女");
?>

のように配列データを記述したファイルを事前に用意しておき、都度そのファイルを参照すれば、データベースと同じ機能を得られると思います。

そこで質問ですが、このような場合、事前に配列データを設けてそのデータを参照するのと、データベースを参照するのと、どちらがお勧めなのでしょうか？
ご意見伺えれば幸いです。よろしくお願いいたします。

Answer 1

たしかに性別・血液型など追加・変更・削除が起きる可能性がほぼ無く選択肢も少ない場合は別テーブルに定義するのは大げさと思います。

かといって今回のプログラム側の配列を参照する方法も、記録されたデータが "血液型: 3" と意味を失ってしまう（値から意図する情報が直接得られない）課題があります。

MySQLをはじめ主要なRDBに用意されている ENUM型 というデータタイプを使ってみてはどうでしょうか？

CREATE TABLE member (
    name varchar(64) NOT NULL,
    gender ENUM('男性','女性') NOT NULL,
    blood ENUM('A','B','O','AB') NOT NULL
)

ENUMは指定したリストの値のみを持つようにできます。また内部的には数値として記録されるので varchar よりもデータサイズが小さくなり、高速に動作します。個人的には都道府県くらいまでなら ENUM でもいいかなと思っています。

それ以上増えたり変動する可能性がある場合は、別途テーブルを作り外部キー制約を使うようにすればよいと思います。

Comments

[chapp]

miyahanさま

貴重なアドバイスをありがとうございます。お恥ずかしながら、これまでENUM型を知りませんでした。今回アドバイスをいただき調べていますが、今後のテーブル設計においても幅が広がりそうな気がします。ありがとうございました。

Answer 2

「格納の話」と、格納されたIDを「表示用の名称に変換する話（DECODE）」の２つと理解しました。

根底にあるのは、

一般的にはデータベースにすべて入れるの一択です。

というのに私も賛成です。
とはいえ、マスタなくても0：不明、1：男性、2：女性とかメモで管理するのは、よくやります。

格納は、ENUMを利用するにしても表示名を格納しないほうが良いと思います。

表示処理については、テーブルとJOINして表示名を取得するというのもありますが、
単純に多言語対応とか考えるとアプリ側（PHP）でやっても良いかと思います。
※あとはデコード関数とかあるけど、それを使うぐらいならアプリ側でやります

Comments

[chapp]

momon-gaさま

貴重なアドバイスをありがとうございます。
多くの方のご意見・考え方がとても参考になります。ありがとうございました。

Answer 3

事前に配列データを設けてそのデータを参照するのと、データベースを参照するのと、どちらがお勧めなのでしょうか？

どっちも正解、好きなように作ろう。
ただし静的なテキストデータで残す場合はゴミデータがあちらこちらに散らばらないように工夫してね。

---

配列データを記述したファイルを事前に用意しておき、都度そのファイルを参照すれば、データベースと同じ機能を得られると思います。

その通り！
データベースに入らなければならない情報は、
そのデータがなくなってもサービスとしては成り立つけど、高速に読み書き追記が出来なければならない情報のみ。
それ以外は設計次第なので、自由に決めれば良い。

登録フォームの性別や年代、血液型などはコロコロ変わる情報ではないね。
一生変わらないような情報はデータベースに格納する必要はない。
（血液型はポジティブ、ネガティブの区分もあるし、性別の区別がない宇宙人や異世界人が住み始めたらどうすんのって話はあるけど…）

別にDBに入れてもいいけど、登録フォームを表示するためだけに2つ以上のSQL文発行する？
PHPに落とし込むと色々含めて10行程のおまじないになりかねないから、私はやりたくないなぁ……

SELECT * FROM sexes ORDER BY id;
SELECT * FROM bloods ORDER BY id; -- どう見てもロスのストリートギャング

まぁ、似たようなフォームを大量に生成するシステムで、
出力項目がフレキシブルな設計にしておきたいとかいう思想の元作られている場合、
性別や血液型もDBに組み込むべきだったりする。この辺も含めて思想や設計次第ってわけだね。

---

さて、話を元に戻して

ソースコードにベタっと書いておきたい情報は定数として宣言されることが多い。
index.phpやconfig.php等という絶対通るファイルに下記のような感じで定数を定義しておけば、
コードのどこからでも自由にアクセス出来る。

if (!defined('SEX')) {
  define('SEX', [
    1 => '男',
    2 => '女',
  ]);
);

※ PHP7.0以降は定数で配列を宣言出来るようになった

Comments

[chapp]

miyabi-sunさま

貴重なアドバイスをありがとうございます。

>データベースに入らなければならない情報は、そのデータがなくなってもサービスとしては成り立つけど、高速に読み書き追記が出来なければならない情報のみ。

>登録フォームの性別や年代、血液型などはコロコロ変わる情報ではないね。
>一生変わらないような情報はデータベースに格納する必要はない。

とのご意見、他の方から「そもそもそこまで正規化しないという手はある」との意見もあり、まだまだぼんやりですが、テーブル設計に関し「こうした方が良いのかな・・・」的なものが、見えてきたような気がします。
貴重なご意見ありがとうございました。

Answer 4

一般的にはデータベースにすべて入れるの一択です。
データベースのみで別のロジックを働かせる（例えば解析等）を実施しようとした時に、データベース内にすべてのデータが入っていないと、働かせようがありません。

追記
質問の主旨とはズレますが、そもそもそこまで正規化しないという手はあると思います。

Comments

[chapp]

te2jiさま

貴重なアドバイスをありがとうございます。
「一般的にはデータベースにすべて入れるの一択です」とのコメントに納得しながらも、「そもそもそこまで正規化しないという手はある」とのコメントに、考えさせられました。取り扱うデータを見直します。ありがとうございました。