

データベースの設計で悩んでいます。

例えばユーザー情報用のデータベースを作るとします。

* * *

### users

  * id
  * name

* * *

これに性別を持たせるときは

* * *

### users

  * id
  * name
  * sex_id

### sexes

  * id
  * name

* * *

これでよいと思うのですが、例えばグループを持たせたいときにすごく悩んでしまいます。

* * *

### users

  * id
  * name
  * group_id

### groups

  * id
  * name

* * *

こうしてしまうと、将来複数のグループを持たせたいとなった時に融通がきかなくなると思います。  
なので

* * *

### users

  * id
  * name

### groups_users

  * id
  * user_id
  * group_id

### groups

  * id
  * name

* * *

このように中間テーブルを挟むことになると思うのですが、将来必要になるかどうかわからないものを最初からこのように設計しても問題ありませんか?  
必要になってから工事するくらいなら・・・と思ってしまうのですが。

みなさんはどうしてますか?  
失敗談などもあれば是非教えて下さい。


CC BY-SA 3.0
2015-03-30T15:54:34.930
8579
2015-04-01T04:04:27.173
2015-04-01T04:04:27.173
49
5855
question
mysql データベース設計
データベースの設計について


一言にグループと言っても  
単一所属グループの場合、複数所属グループの場合、階層型グループの場合。  
複数グループに所属して、その中で優先グループをもつ場合もあります。  
どれを想定するかで適切な設計が決まります。

今迷っているのは将来の拡張性ではなく、まだグループの要件が詰めきれていないからではないでしょうか。  
もしそうなら、決定まで設計は待った方がいい気がします。


CC BY-SA 3.0
2015-03-31T03:58:13.427
8589
2015-03-31T03:58:13.427
8431
8579
answer


「将来を見据えた設計をすべし」とも言われますし「将来を見越しすぎるのは無駄」とも言われます。正解はありません。

こういう状況で様々な要素を判断してよりベターな選択ができるのが設計者のスキルそのものです。


CC BY-SA 3.0
2015-03-31T06:48:17.867
8597
2015-03-31T06:48:17.867
5793
8579
answer


フレームワーク的なアプローチで考えてみますね。  
user.groupでドバーっとあちこち書きまくったやつを、  
user.groupsにしたらレコードインスタンスだったものが配列になるので大変です。  
それなら最初から「常に配列だけど現状１件しか帰ってこないよ」の方が気が楽です。

しかしその場合でもuser.groups.firstとか書いちゃったら意味がありません。

以上のことから  
「groupsが複数あること前提で設計する（＝複数きた時の挙動が定義できる）」  
かどうかが判断材料としています。現時点で定義できないなら書くよりも  
「そのときは、変更コストかかりますからね？」と釘刺したほうがストレスなく済みますよ。 ：）


CC BY-SA 3.0
2015-03-31T08:15:14.033
8603
2015-03-31T08:15:14.033
8335
8579
answer