Q&A
現状の問題点は何でしょうか。
初学者でさらに迷いが出てきたので、お聞きしたいです。
現状どちらの考え方or別の考え方でテーブルを作るべきかと思った次第です。
DBでの表現方法はたくさんある気がしていて、このパターンならこれで十分、この観点が抜けてるなど教えていただきたいです。
こちらの質問の類似となっております
https://teratail.com/questions/329551
表現したいこと
userがコミュニティに参加できるサービスで、それぞれのコミュニティ上でプロフィール名を設定と、通知の有無を設定できます。
コミュニティに参加時には、notification_settings.is_allowは1で作成され、
profileは作成されません。
自分の設定画面から設定するとデータができるようにしようと思っております。
また参加した際には、参加の日付がログとして残そうと思っています。(join_log)
コミュニティから退会した場合は、ログ以外のデータは全て削除する予定です。
DBの設計にあたって
DBパターン１
DBパターン２
全てのデータを消そうと思っているので、 delete cascadeをつけて
サロゲートキーで引っ張ってこようと思っています。
DBパターン３
上記とは違う何か案があれば教えていただきたいです。
申し訳ないです！現状の構造に問題点があるかどうかなどをプロの方の目線から知りたかったです！ついきしました！
「プロの方の目線」だとそれは質問ではなく作業依頼となります。プロはそれで仕事して生きてるわけですから。
イライラしてますね〜誰もあなたの価値観について話してないですよ＾＾b
これまでのあなたの回答はお金がもらえないから、適当に回答してるってことですか？
ちなみに「プロの目線」というのは自分より経験がある方からの指摘が欲しかったという意味なので誤解しないでね＾ー＾b
回答1件
0
パターン1の community_user テーブルに notification_settings と profile を統合して一つのテーブルにすればいいと思います。
それぞれのテーブルにレコードが作成されるタイミングがバラバラなら分ける意味があると思いますが、例えば community_user にはある組み合わせでレコードが作成されるのに、 notification_settings に同じ組み合わせのレコードが存在しないタイミングがありますか？
「コミュニティに参加する」タイミングで同時にデータを作成することになるのではないでしょうか？
そもそも質問のタイトルにある「ナチュラルキー」の用語の使い方がそもそもおかしい気がします。
たとえば、 user_id = 1 であるときに 1 に何かユーザーの属性を示す情報が含まれていますか？
投稿2021/04/30 11:11
総合スコア6759
後出しでごめんなさい！追記させていただきましたが、
> コミュニティに参加時には、profileは作成されません。
> 自分の設定画面から設定するとデータができるようにしようと思っております。
ですので、アドバイス通りからすると
profileは別にして、settingは一緒にしようと思っています！
もしくはprofileもnullで作っちゃっても良さそうですね（その場合は一緒なテーブルに）
>そもそも質問のタイトルにある「ナチュラルキー」の用語の使い方がそもそもおかしい気がします。
こちらおかしいですね！複合主キーですよね？
あなたの回答
tips
プレビュー
