チャットアプリを作る⑴
チャットアプリを作る
前回の記事でブログアプリを作ると書きましたが
実は並行してチャットアプリも作っていて
今日はそのチャットアプリのDB設計をしたので
実際に行なった設計フェーズについて書こうと思います。
DBを設計する
アプリケーションを実装していく前に、作成するアプリのDBの設計をちゃんと考える必要があります。
私は普段から考えたことをすぐに行動に移したいタイプなので、アプリを作成するときもすぐに実装に取り掛かりたくてうずうずしてるんですが、
作っていくうちに複雑化してしまう可能性があったり、あとで必要な機能を思いついてめんどくさくなったりするので、本当にこの設計というフェーズはすごく重要ですね！（当たり前）
正直この作業私にとってめちゃめちゃ面倒です！
これって女性の思考回路にも関係してるんじゃないかなあと思いました。
会話に関しても男の人は割と理論的に何かしら伝えたいことがあって、
そこに向かって順序立てて話していくじゃないですか。
それに対して女の人は
「今日ね友達とランチしててね、面白いことあったんだけど〜
ランチといえば今日大学の近くのお弁当屋さんが〜」みたいに、
どんどん思いつきで喋ってるんですよね。
だから頭のなかって割とごちゃごちゃで
いろんなことが頭の中に整理せずに入ってる気がします。
会話だけじゃなくて男の人の方が空間認識能力が高いのは有名な話で
物事の構造を把握するのはやっぱり男の人は得意なんだろうなあと、ふと思いました。
ぜんぜん関係ないですが、男女の思考の違いについて面白い記事があったので引用しておきます笑
話は逸れましたが私も構造認識が苦手なうちの一人なので、
めんどくさいと思ってもここが踏ん張りどころ！と思って頑張るしかないですね。
実際このDB設計をやることで頭の中を整理することができて
アプリケーションの全体把握が正確に行えるようになりました！
なので、女性は特に！ここの部分はしっかり時間をかけて行なった方がいいですね。
機能を把握する
データベースを作成する前にアプリケーションに搭載する機能について
明確化する必要があります。
今回は簡単なチャットアプリなので機能はこんな感じです。
ユーザーがログイン・ログアウト・アカウント編集→ユーザー管理
グループを作ってその中でメッセージのやりとりをする→グループ管理
メッセージを送信してチャットを行う→メッセージ管理
こうして整理すると、３つのデータの管理をする必要があり、
それぞれにテーブルを設計する必要があることがわかります。
テーブルの関係性を考える
次に上記で書いた３つのテーブルの関係性について考えました。
実際に私が書いたER図です。汚くてすみません、、、！
ここでポイントなのが、ユーザーテーブルとグルーブテーブルの関係性です。
どちらも多対多の関係性になっています。(あるユーザーは複数のグループに所属する。
あるグループには複数ユーザーが所属する。)
この場合テーブル同士のアソシエーションを記述していくために、
「中間テーブル」というものを利用しなければいけませんでした。
中間テーブルについてはわかりやすく解説してあるブログを見つけたので
引用しておきます。
今回は中間テーブルとして、メンバーテーブルを作成することで多対多を解決しました。
テーブルに必要なカラム・型・オプションについて考える
テーブル同士のアソシエーションが考えられたら、
次はテーブルに必要なカラムが何かを考えてそのカラムの型とオプションを考えました。
ここで重要なのはオプションです。特にオプションの中の制約はアプリを作るで大事な部分でもあり、テーブルのカラムに対して制約をかけることで不正なデータや予期せぬデータが保存されることを防ぐことが出来ます。
- NOT NULL制約
- 一意性制約
- 主キー制約
- 外部キー制約
これらの制約を使うべきかどうか考えながらオプションを設定していきました。
以上の設計ができれば、DB設計は完成です。
実際に行なったテーブル設計図は以下の通りです。
汚いですが手書きの設計図も一緒に載せておきます。
