ER図を追加しました

[KentoBF5587]

READMEにER図のリンクを貼り付けました。 よろしくお願いします。

※QuestionsテーブルとResultsテーブルは本リリースの際に実装予定の分岐診断のためのテーブルです。 今回はログインなしでも利用できるよう、Usersテーブルとは紐付けず診断結果を保存しないケースを考えてテーブルを作成してみました。

また130行目に記載したrailsのバージョンに誤表記が確認されたため、変更を加えました。

[kenchasonakai]

ER図の確認が出来ませんでしたのでアクセス権限の確認やER図のスクリーンショットを貼るなどでER図が確認できるように対応お願いいたします

[KentoBF5587]

申し訳ありません。 こちらのコメント欄よりREADMEに書かれたリンク先のER図のスクリーンショットを添付します。

なお、前回の提出時には共有の設定を以下の画像のようにしているのですが、反映されないとすると「（コメント可）」にしているのが原因でしょうか……。

[kenchasonakai]

どのテーブルがどんな役割なのか知りたいので各テーブルと役割をこのプルリクエストのコメント記載をお願いします

また、購入履歴のことをBuyBooksと表しているのであれば動詞を使うのではなくPurchaseHistoriesのように名詞になるようにしてあげると良いかもしれません

[kenchasonakai]

なお、前回の提出時には共有の設定を以下の画像のようにしているのですが、反映されないとすると「（コメント可）」にしているのが原因でしょうか……。

わからないですがもしかしたら共有用のURLになっていないのかもしれないですね

[KentoBF5587]

レビューありがとうございます。

Usersテーブル→ユーザー登録・ログイン機能（TwitterAPIもしくはメールアドレスでの作業を想定）、行ってみたい本屋設定・解除機能、書店レビュー機能、書店レビューへいいね・いいね解除機能（本リリース後）、プロフィール作成・編集機能、書店レビューした本屋（おすすめの本屋）に紐付けてユーザーが購入した本を紐づけて記録する機能

Bookstoresテーブル→書店検索機能、書店情報投稿・編集・削除機能、行ってみたい本屋設定・解除機能、書店レビューした本屋（おすすめの本屋）に紐付けてユーザーが購入した本を紐づけて記録する機能

Tags・TagRelationsテーブル→書店検索機能（タグ検索）、タグ設定機能

StoreReviewsテーブル→書店レビュー機能、書店レビューへいいね・いいね解除機能（本リリース後）

ReviewLikesテーブル→書店レビューへいいね・いいね解除機能（本リリース後）

WannaGoテーブル→行ってみたい本屋設定・解除機能

PurchaseHistoriesテーブル→書店レビューした本屋（おすすめの本屋）に紐付けてユーザーが購入した本を紐づけて記録する機能

Contactsテーブル→問い合わせ機能

Questions・Resultsテーブル→診断機能（本リリース後）※今回はログインなしでも利用できるよう、Usersテーブルとは紐付けず診断結果を保存しないケースを考えてテーブルを作成してみました

また、ER図の中央にあったBuyBooksテーブルの名前を、PurcharseHistoriesテーブルに名前変更しました。ありがとうございます。

[tmtkzk0823]

修正ありがとうございます。 以下、追加のコメントになります。

---

全体

• created_at, update_atカラムが、表示されていたり、されてなかったりする箇所があるので統一をお願いします。

PurchaseHistoriesテーブル

• purchase_dateカラムは命名はdateですが、データ型はintger型で正しいでしょうか？ご確認をお願いします。

StoreReviewsテーブル

• first_body~sixth_bodyこれらのカラムは、なぜ分けているかのイメージができなかったのでご説明をおねがいします。

[KentoBF5587]

レビューありがとうございます。

全体

• created_atカラムと、updated_atカラムを全てのテーブルに付け加えました。

PurchaseHistoriesテーブル

• purchase_dateテーブルはdate型の間違いでした。なお、こちらのカラムはユーザーに購入日を選択してもらうことを想定しています。例. 2024年4月21日、2023年3月など。

BookReviewテーブル

• 説明が不十分でした。こちらはレビューの内容を保存するもので、6種類の質問をそれぞれのカラムで保存するようにしています。

first_body →書いた日付を入力してもらうためのカラムです。date型

second_body →その本屋を知ったきっかけを書いてもらうためのカラムです。string型

third_body →初めて行ったのはいつ頃かを書いてもらうためのカラムです。日付ではなく文字入力の方が書きやすいかもしれないと考え、string型。

（4つ目の質問→この本屋に当てはまるタグを選んでもらいます。この選んだタグがBookstoresテーブルに反映され、"本屋検索機能"や"本屋投稿詳細ページ"に反映される実装が出来れば面白そうだなと現在考えています。）

fifth_body →この本屋のどんなところが好きかを書いてもらうためのカラムです。string型

sixth_body →この本屋についての思いを自由に書いてもらうためにカラムです。他の項目よりも長く書けるように、string型ではなくtext型にしました。（バリデーションで最高〇〇字と文字数制限はする予定です）

---

以上の点を踏まえER図に修正を加えました。 よろしくお願いします。

[Tsuchiya2]

対応ありがとうございます。 以下コメントになります。

---

・first_body, ...：カラム名から何を登録したデータなのかが分かるようにしましょう。

[KentoBF5587]

レビューありがとうございます。

StoreReviewsテーブルのカラム名を以下のように変更しました。

first_body→date_enteredカラム 書いた日付を入力してもらうためのカラムです。date型

second_body →opportunityカラム その本屋を知ったきっかけを書いてもらうためのカラムです。string型

third_body →first_visitカラム 初めて行ったのはいつ頃かを書いてもらうためのカラムです。日付ではなく文字入力の方が書きやすいかもしれないと考え、string型。

（4つ目の質問→この本屋に当てはまるタグを選んでもらいます。この選んだタグがBookstoresテーブルに反映され、"本屋検索機能"や"本屋投稿詳細ページ"に反映される実装が出来れば面白そうだなと現在考えています。）

fifth_body →favoriteカラム この本屋のどんなところが好きかを書いてもらうためのカラムです。string型

sixth_body →free_descriptionカラム この本屋についての思いを自由に書いてもらうためにカラムです。他の項目よりも長く書けるように、string型ではなくtext型にしました。（バリデーションで最高〇〇字と文字数制限はする予定です）

以上の変更をER図に反映しました。 よろしくお願いします。

[shota-hope]

修正と解説ありがとうございます。

fifth_body →favoriteカラム この本屋のどんなところが好きかを書いてもらうためのカラムです。string型

細かい&個人差がありそうな指摘で恐縮ですが、favoriteカラムだと文章が入っていると予測されない可能性もありそうなのでfavorite_reason等、文章が保存されているとわかりそうな命名がいいかなと思いましたがいかがでしょうか。

ご確認よろしくお願いいたします。

[KentoBF5587]

レビューありがとうございます。 favoriteカラムだと形容詞だけだがどうなのだろうと考えていたので、ありがたいです。

StoreReviewテーブルのfavoriteカラムをfavorite_reasonカラムと名前変更しました。 よろしくお願いします。

[ky0613]

概ね良いかと思います。LGTMです！