素人が2020年までの1ヶ月でLINE BOTに挑戦する毎日note. 【Day 19：DBスキーマの定義 part 3】

こんにちは！
12月1日から2019年残り1ヶ月でスケジュール調整BOTの開発に挑戦している"くろ"です。

昨日の記事からカバー写真を全部自分で撮影したやつにしました。

記事とは全然関係ないですが、昨日と今日の写真はこの間行ってきた二条城のNakedがやっていたプロジェクションマッピングイベントの写真です。

BOTの概要：Day 2の記事

BOTの仕様：機能一覧やフローチャート Day 10の記事

昨日はDBスキーマの定義part 2として、Entityの定義をしていきました。

今日は、作成したEntityにFB内容を反映してFIXさせることと、その解説をします。

可能であれば2番目以降にも手を付けたいと思います。

1，Entity　←　イマココ
2，Repository
3，Service logic
4，Controller

昨日作成したものがこちらです。

もらったFBも含めて、1つ1つ解説していくと、

オレンジのセルがEntity classの名前で、
typeは型（＝その変数がどんな変数なのかを定義したもの。基本的には、ある変数を使う時はその変数がどんな種類なのかを先に宣言する必要があり、その宣言した種類以外のデータは代入できないというのが型の考え方です。）、
attributeとcommentはその名前の通りです。
（この2つは多分書かなくてもいいけど、わかりやすいように書いてます。）

※JavaScriptは動的型付けの言語と呼ばれる言語で、変数が直接的に特定のデータ型に関連付けられているわけではなく、いかなる変数にあらゆる型の値を代入することができるようになっています。
なので、言うなれば型のない言語なので、型を意識して指定する必要は無いのですが、汎用性をもたせるためと理解のためにtypeを書いてます。

中身について

※変更点は太字にしてます。

user

↓修正版↓

名前の通り日程調整をするユーザーを表していて、要素としては、id（ユーザーのID）、line_uidとgoogle_id（GoogleとLINEの裏側でのユーザー識別子）、mail（何かあった時のために一応いれてます。）で構成しています。

idはbigintという型、line_uidとgoogle_id、mailはvarcharという型を利用してます。

※bigint
整数が入れられる型です。
範囲が-2^63 (-9,223,372,036,854,775,808) ～ 2^63-1 (9,223,372,036,854,775,807)になるようです。

※後ほど出てくるint型も整数が入れられる型で、
範囲が-2^31 (-2,147,483,648) ～ 2^31-1 (2,147,483,647)になるようです。

整数データを使用する実数データ型です。 データベースの容量を節約するために、すべての可能な値を確実に含めることができる最小のデータ型を使用します。 たとえば、255 歳以上の人は誰もいきていないので、人の年齢には tinyint で十分でしょう。 しかし、255 年を超える建物はあり得るので、建物の経過年数には tinyint では不十分になります。

https://docs.microsoft.com/ja-jp/sql/t-sql/data-types/int-bigint-smallint-and-tinyint-transact-sql?view=sql-server-ver15h

※VARCHAR(M)
可変長文字列
M は最大文字数。M の範囲は 0 から 65,535 。
ただし使用する文字コードで使うバイト数による。
別名：CHARACTER VARYING
https://www.dbonline.jp/mysql/type/index3.html

created_atとupdated_atはこのデータ1つ1つが作られた時と更新日を記録しております。
ここの型はdatetimeの方がいいということだったので、変更しました。

datetimeとtimestampの違いhttps://qiita.com/ykawakami/items/2449a24e3b82ff0cbab6

created_byとupdated_atはどのアプリケーションがこのカラムを作ったのかを記録するのですが、今回だとアプリケーションが1つになる可能性があるので、その場合はなくてOKとのことでした。一旦ちゃんとアプリケーションを理解できてないので、残してます。

※最初ユーザーIDをuser_idと書いていたのですが、userというclassの中ではidはこれしかないので、そういう場合はidと書くほうが良いみたいです。また、他のclassでユーザーIDを使う時は、user_idといった感じで書くみたいです。userっていうclassのidっていう要素っていう感じだと理解してます。

schedule

idは基本的に全てのEntityクラスに入っていてカラムの番号のようなものだと思って大丈夫だと思います。

parameterは、どのscheduleなのかを判別するための識別子ですが、tokenの方がいいよってことだったので、変更しました。

deadlineは期限、start_time、end_timeは候補の時間で、条件情報です。
候補日付は後述しますが、別のEntityにしてます。

timeover_pushは期限超過したよっていう通知を停止してくれるまで毎日送り続けなくて済むように判別する識別子として入れています。（もう予定決まってる場合にユーザー的にうざいのと、pushコスト、負荷的なコストがあるなどの理由からです。）

validityは、停止したときに無効にする判別のためです。

owner_user_idは、元々別でschedule_ownerというEntity_classを設けていたのですが、要素がidだけだったので、scheduleと1:1やんってなってここに統合してます。なので、schedule_ownerはなくなりました。

schedule_member

日程調整メンバーのEntityです。

schedule_idはどの日程調整のメンバー情報なのかを判別するために入れています。user_idはそれが誰なのかがわかるようにいれてます。

prospective_date

scheduleの条件情報の1つが、どの日付で調整したいか選ぶ所だと思うのですが、この時選ぶ日付は複数あるので、scheduleに対して、1:nになります。なので、候補日は別のEntityにしました。開始時間や終了時間は1:1にするので（日毎に何時の予定があいてるか知りたいとかあんまりないと思うので。例）21,22,23日の中で、19－21時の空いてる所に予定入れたい的なニーズが多いかなということです。）

google_calendar

nameはGoogleカレンダーの名前で、一応取ってます。
想定要素としては、複数のカレンダーをgoogleカレンダーで作っている場合に、どのカレンダーの予定が反映されているか？やそれを変更したい時が出てきそうだなという意図です。

※nameは最初はなくても回るかもしれないので、省く方が正解かもです。

google_event

これはカレンダーの中の予定1つ1つの情報です。

calender_idは、どのカレンダーの予定情報なのか？
nameは予定の名前（飲み会とか）
date、start_time、end_timeは予定の日時です。

response

これは回答情報のentityです。なんて回答したかですね。

prospective_date_id：日程候補日ごとに○△□の回答情報と被っている予定が記録できればいいので、キーを日程候補日にしています。

response：○△□の回答情報です。bigint ⇛ intにしてます。

response_event

回答情報の内、被っている予定の情報がこれです。可能性として、候補の時間の中で複数の予定が被っている場合がありそうだなと思ったので、別のEntityにしてます。下図の22日のパターンですね。18時～24時で空いてるかどうかが知りたい場合。

書いてて思ったんですが、18－24時の中で1時間空いてる所を探したい時もあるなと思ったのですが、その要素を入れると複雑になりそうなので、一旦候補時間の中に予定が被っている時間があるかどうかで出すことにして、個人で変更してもらうようにしたいと思います。

response_id：候補日ごとに回答情報があるので、それに紐付けておく。
event_name、event_start_time、event_end_timeは被っている予定の情報です。

ここまでがEntityの解説になります。

分量も多くなったので、2番目以降は明日以降の記事にさせてください。

↓この辺

2，Repository
3，Service logic
4，Controller

本日は以上になります。