ユーザーがコミュニティに参加できて、それぞれのコミュニティで「名前」を設定できるDB設計について

Question

質問したいことは表題通りです。

tableとしては

Users

• id
• email
• password
• その他カラム

communities

• name
• description
• cover_image
• その他カラム

上記を紐付ける中間テーブル community_user

• user_id
• community_id

を持って紐づけております。

そこで、表題の「それぞれのコミュニティでユーザー名を決めれる」という機能の場合

解決策①

community_user tableにnicknameを生やしていく

解決策②

profile
- id
- user_id
- community_id
- name

のようなtableテーブルを作成する

中間テーブルの役割にそのほかの役割を増やしていいのか、
今後プロフィール画像を設定できる。自己紹介がかけるなど拡張があった場合も想定した時どのような設計がいいのか
など悩んでおります。
よろしくお願い致します。

Answer 1

・名前を変更した場合、過去分も含めて変わってしまってよいのか
・一度コミュニティから抜けたあとに再入会した場合、最初のユーザと同じ扱いでよいのか

いずれかが No なら profile テーブルもアリではと思いました。

Comments

[php_practitione]

ありがとうございます理解が深まりました
>・名前を変更した場合、過去分も含めて変わってしまってよいのか
たしかに履歴を持っておきたいなどの場合があると、
community_userとprofileの履歴情報を別で管理しないとややこしくなりそうですね。

>・一度コミュニティから抜けたあとに再入会した場合、最初のユーザと同じ扱いでよいのか
こちらが少しわからないのですが、
現在はコミュニティから抜けた際にりれーしょん情報を物理削除しようと思っています。
となると
再加入した場合に「前回の情報を残しておきたい」ならcommunity_userとprofileの２つで管理
再加入した場合に「全部消えていい、0からスタート」ならcommunity_userに持たせればOK
ということでしょうか？

書いてて気づきましたがリレーションを論理削除する手もありそうですね。。。

Answer 2

それぞれのコミュニティでユーザー名を決めれる

という事なら、コミュニティとユーザーで決まる情報であるので、community_userに保持する事で良いかと思います。

中間テーブルという言葉で単に複数のエンティティの関連を示す情報のみのようなイメージがあるなら、そのイメージは捨てて下さい。
れっきとしたエンティティです。
一意なナチュラルキーでみると、質問のprofileとは同じキーですから、敢えて別なテーブルにする必要は無いと思います。

Comments

[php_practitione]

ご回答ありがとうございます。
そのイメージがあったので一意なキーで同じ場合は今後そのようにしたいと思います

[sazi]

サロゲートキーを持つために、profileを利用して、community_userの役割も持たせるという事でも良いと思います。

[php_practitione]

ご回答ありがとうございます。
現状の回答だと、profileと中間テーブルを　別々に持たせる意味はそこまでない。
一緒のテーブルでナチュラルキーかサロゲートキーどちらか好きな方で選んで
と受け取っております

例えばですが、今後もプロフィール情報以外の情報もコミュニティ毎に追加していく場合でも
上記のテーブルにはやして行けばいいのでしょうか？
profile情報というものと他の情報がテーブルに混ざることが気になっております。(その場合はテーブル名はprofileではなく、リレーション的な名前)

あまり良い例が思い浮かばず、もしかするとそのパターンはないのかもしれないですが。。。

[sazi]

そもそも中間テーブルというのは、データベースのモデル化が進んだ時に出てきた概念で、正規化では言葉として存在しません。
> 今後もプロフィール情報以外の情報もコミュニティ毎に追加していく場合でも
上記のテーブルにはやして行けばいいのでしょうか？

正規化に照らして、正当な場所に配置して下さい。

[php_practitione]

概念的なことで難しいですね。。。

[php_practitione]

再度、mysqlの本などを読み直して正規化あたりを学習しているのですが、

「正当な場所」というのがどう決まるのか、がいまいちわかっておりません。
どのような調べ方や学習方法などご教示して頂ければと思っております。

上記の質問での、コミュニティIDとユーザーIDで一意になる所に追加情報をもたせたい（ユーザー名）という場合
自分はアプリケーション側の話から考え方が入ってしまったので、profileテーブルを作ろうとしたのだと思っています。
さらに追加でコミュ、ユーザーで一意な固有のコミュニティの招待コードの発行機能がついた場合
invitation_codeというtableを作り、commuity_id, user_id, code のようなテーブルを作ってしまうと思います。（履歴とか考慮なし）
でも上記の回答からすると
community_user tableにcodeを持たせればよく、別テーブルにする必要がそこまでない
となると思っています。

データベース側からみたとき、追加情報が増えた場合でも一意になるキーが一緒なんだから、カラム数が増えていくけどそれが正しい
となるのか
profileは分けようよ、invitation_codeはそのままでいいよね
となるのか
その境目となる学習方法や単語などを知りたいです。

よろしくお願い致します

[sazi]

>「正当な場所」というのがどう決まるのか、がいまいちわかっておりません。
「正当な場所」というのは正規化の結果です。

正規化に照らし、追加する情報がどういったキーの属性情報になるのかを確認し、そのキーを持つテーブルに配置する事が基本です。

ただ、同じキーであってもエンティティが異なればテーブルを別にする事もあります。
なので、正しくはどのエンティティに従属するのかを吟味して配置するという事になります。

エンティティは項目の集まりなので、追加しようとする情報が別エンティティなら、テーブルを新規とする事もあり得ます。

上記のような内容を理解するにはある程度学習が進んでいないと難しいのではないかと思います。

[sazi]

そもそも、今後も含めてどのように設計すれば良いかという質問に対する、ベストな回答は出来ません。
具体的な現状に対して、問題が無いかという質問に対してのみ、ベターな回答が出来る程度です。