質問: 今、カレンダーアプリを作っています。グループと呼ばれるものをフォローすることで、そのグループに登録された予定がカレンダーに表示されるというものです。 また、ユーザーごとにフォローしてるグループを管理するので、必要となるのはグループとグループの予定、ユーザーに関する情報です。この場合はどのようにデータベースを設計すれば良いのでしょうか? ...ただ聞くのも申し訳ないので、初心者なりに僕も考えてみました。まず、グループはIDとグループ名を保持するに留め、グループに予定を含みません。そして、予定のテーブルを作り、予定にグループのIDや日付といった情報を格納します。ユーザーはフォローしてるグループIDをJSON形式なりで保存(ここはどうなのでしょうか...)と考えています。 これはリレーショナルデータベースをうまく活用できているのでしょうか?
回答: 手探りでデータベース設計をするのはなかなか無理があるので E-R図を書いて整理していくといいですね。 参考URLは良い記事だと思います。 *出来ればごく簡単なもので良いのでDB設計の入門書を一冊終わらせるのをお勧めします。 さて、 今回のケースですが、 ぱっと見てJSONで保存しているのはあんまりよろしくないです。(場合によってはありですが、必要なケースはあんまり無いです) JSONなどの形式で保存してしまうと、検索が超遅くなってしまいますし、RDBMSの特徴であるフィールドの値をキーにして表を関係させていくという利点がなくなってしまいます。 > > グループはIDとグループ名を保持するに留め、グループに予定を含みません。 > > > これは良い設計です。 > > 予定のテーブルを作り、予定にグループのIDや日付といった情報を格納します。 > > > これもいい設計です。 > > ユーザーはフォローしてるグループIDをJSON形式なりで保存(ここはどうなのでしょうか...)と考えています。 > > > ここは前述の通りあんまりよろしくないです。 SQLのみで「そのユーザがフォローしているグループ名を含めた表」を作る事が出来ない構造になっていま す。またフォローするグループが多くなると更新や表示が劇的に重くなってしまうことでしょう。 ではどうするかというと、グループとグループ予定テーブルを分けたのと同じように、 ユーザーとユーザーのフォロー情報を分けてあげればOKです。 ユーザーのフォロー情報テーブルには最低限 ユーザーIDとフォローするグループID が含まれていればOKですね。 グループとグループ予定の考えが出来ているのでここまでの説明で行けると思いますが、 追加の説明が必要ならコメントを下さい。