複数選択か？単数選択か？ テーブルは分けるか？

選択項目が、複数選択か単数選択か決まってない場合、データベースの設計はどのようにしますか？

例えば、性別や現住所の都道府県等、複数選択する可能性がないものは、親テーブルに定義しています。
例）
プロフィールテーブル
| id | 氏名 | 性別 | 都道府県 |
|　1 | 山田 |　　1 |　　　 14 |

また、絶対に複数選択の項目は、テーブルを分けます。
例）
アイテムテーブル
| id | プロフィールid | アイテム |
|　1 |　　　　　　　1 |　　　　2 |
|　2 |　　　　　　　1 |　　　　5 |
|　3 |　　　　　　　1 |　　　 12 |
|　4 |　　　　　　　1 |　　　 16 |

では、複数選択になるか単数選択になるか決めかねている項目は、どうすればいいでしょうか？
（例えば、「いちばん好きな食べ物をお選び下さい（単数選択）」を「好きな食べ物をお選び下さい（複数選択）」に変更するということは、普通にありえることですよね？）

テーブルを分けた場合、複数選択になっても問題はないですが、データを抽出するのにjoinしなければいけないので、面倒だし、パフォーマンスが悪くなる気がします。

皆さんの意見を聞かせてください。
※それとも、私の考え方自体が間違ってるのでしょうか・・・。

No.2 ベストアンサー 回答者： ibushi_007 回答日時： 2007/12/18 23:51

理想を言うと、先に仕様を固めたほうが良いです。

それが難しいのであれば、#1の回答者様もおっしゃられた通り、
変更があった場合に面倒でない設計にしておくべきでしょう。

ですので、この場合でしたら分けておくのが妥当です。
（複数になった場合の面倒さは考えていただければわかると思います。）

この回答へのお礼

ご回答ありがとうございました。

絶対に複数選択にならないようなもの以外は、基本、別テーブルでってことですね。
了解しました。

お礼日時：2007/12/21 00:14

No.1 回答者： yambejp 回答日時： 2007/12/17 10:42

拡張性を考えるとわけるのが妥当。

性別などスタティックなデータはかわらないのでプロフィールテーブル
でもよいですが、たとえば都道府県なんて引越せばかわるでしょ？
こういうダイナミックなデータは分けたほうがいいですよ。
（ま、運用方法によるのでどっちでもいいですが・・・）

「いちばん好きな・・・」もその類の項目が増えたり減ったり
しないなら別ですが、運用過程でその手の項目はよく変わるものです
それを考えると別テーブルで管理するほうが楽です。
（別テーブルであればフラグで管理できるので）

つまり理由が「面倒」なら、ぜひ別テーブルで管理することをお勧めします。
SQLは工夫すれば簡単に書き直せますが、拡張性のないテーブル管理は
「ひじょうに面倒」です。

「パフォーマンス」面では極度に正規化した場合、その弊害が大きいと
思いますが、個人で管理できるレベルのデータでは、パフォーマンスに
大きな差が出るほどの処理はあり得ないと思います
（きちんと最適化さえしてあれば・・・）

この回答への補足

ご回答ありがとうございました。

> たとえば都道府県なんて引越せばかわるでしょ？
引っ越しても、複数の都道府県にまたがって住むことはない（つまり一つ）なので、UPDATEするだけでよい気がしますが、間違ってますか？

> 「いちばん好きな・・・」もその類の項目が増えたり減ったり
項目の増減ではなく、その項目が複数選択か単数選択か、という問題をお聞きしております。

単数選択も、拡張性を考えるて別テーブルにするのは分かりますが、その場合、これはさすがに親テーブルと一緒でもいいだろう、というところの基準があいまいで、皆さんはどうしてるのかな、と思いました。

補足日時：2007/12/18 00:31