Q&A
Userも複数のClubに所属できることを想定しています。
無限長になってしまう、ということですが、関連をMembershipで表しても無限長になってしまう事実は変わらないと思います。
Membershipモデルが必要ないことはないのはわかっているのですが、どのようなメリットがあるか知りたいです。言葉足らずで申し訳ありません。
UserとClubのモデルがあったとして、その関連を表すMembershipモデルのようなものは必要ありますか？
Userにbelong_to_club_ids
Clubにhas_user_ids
のような配列をidを格納する配列を持たせるでは機能的に不十分ですか？
不十分であればどのように不十分であるか教えていただきたいです。
よろしくお願いします。
この質問の投稿者はすでに退会しているため、質問者からの返信がない点にご留意ください。
回答2件
0
ベストアンサー
バックエンドがSqliteやMySQLのようなRDBMSであれば、持たせるべきです。
というのも、UserとClubで、属するデータを二重管理していると、片方を変更したときにもう片方の変更を怠るようなバグを出してしまったときに、どちらが正しいデータだったかわからなくなる、というデータの損失を伴う不整合となるからです。
このように、「1対多」のデータを列方向に開いて、複数の「1対1」データの関連として表現し直すことを、データベースの正規化の1つとして、「第1正規化」といいます。
Railsの場合、has_many through:の形を使えば、このような中間テーブルを入れた多対多関係も簡単に定義できます（なお、Rails wayでは、中間テーブルはclub_usersのような名前が適当です）。
投稿2017/02/04 23:52
総合スコア147065
0
情報が少なすぎて、どんな機能を設計してるのかわかりませんが。。。
Userが1つのClubにしか所属できないのであれば、
Clubモデルにuser_idを持つのではなく、
Userモデルにclub_idを持つべきです。
なぜなら、Clubに対してUserがいくつ紐づくかわからない配列（無限長の配列）になるからです。
データベースに入りきらないですし、現実的ではないです。
ruby
1club.has_user_ids 2# => [1,2,3,4,5,6,78,9,10,11,12...................................∞]
また、Userが複数のClubに所属できるのであれば、多対多の関係になるため、
Membershipモデルを中間テーブルとして作成する必要性が出てきます。
投稿2017/02/04 11:13
総合スコア890
中間テーブルという用語があるのですね？
必要性とは具体的にどのようなものか教えていただきたいです。
Userモデルにclub_idを持てば1つのintegerを持てばいいですが、
Clubにuser_idを持つと、データベースを破壊しかねないカラムができるということです。
多対多の場合は
↑に書いたことと同じように、UserにClubのidを複数持たなくていいように、
MembershipモデルにClubのidとUserのidを持つようにします。
ためしに
1億Userを1Clubに紐づけること
多対多の場合は
1億Userがそれぞれ1億Clubに紐づけること
を想像してみてください
Userはidを複数持たなくて良くなるけど結局Membershipを同じ数だけ持たなくてはいけなくなるのではないですか？
列が増える方向であれば、DBエンジンはかなりのものを吸収できます。逆に、カラムの長さは（TEXTなどを除いて）MySQLで64キロバイトと、相当に制約が厳しいです。
参考までに
MySQL
・Queryの最大長は1MB
・レコードの最大長は約64KB
・テーブルごとの最大レコード数は4,294,967,295レコード（約４Gレコード）
PostgreSQL
・Queryの最大長は2GB
・レコードの最大長は1.6TB
・テーブルごとの最大レコード数は無制限
となっているようです。
検索処理などはデータベースの得意とする能力なので、アプリケーション側でそのidを処理するべきではないです。（重いし負荷もかかる）
百聞は一見に如かずというので、実際やってみるといいと思いますよ。
（データ量が圧倒的に少ない＆速いと思います）
この質問の投稿者はすでに退会しているため、質問者からの返信やベストアンサーの選定がない点にご留意ください。
あなたの回答
tips
プレビュー
退会済みユーザー
2017/02/05 00:32