20201118_アウトプット（ER図・DB設計）
今日行ったこと 5時間
- READMEに記載し、プルリクエストをしてレビュアーをもらった。
（メンターさんからのレビュアーがめちゃくちゃ勉強になった）
新しい発見
レビュアーからの学び（READMEのデータベース設計）
Gem導入によって自動生成されるカラムと、Railsの仕様で自動生成されるカラムは書かなくていい。
例：itemsテーブルのimage 👉 active_storage（Gem導入）
例：buysテーブルのordered_date 👉 timestamps型（Rails仕様）passwordとpassword_confirmのカラムではなくdeviseがあらかじめ用意しているencrypted_passwordというカラムだけで実装可能（シークエルプロをみて考えているときこのカラムなんだろう？と思っていたためすっきり！）itemsテーブルの中に、
item_nameというカラムを作っていたが、itemsテーブルにある時点で、その名前とわかることからシンプルにnameだけでOK。（他のテーブルと区別することを、心のどこかで考えていたことに気付けた）postcode（郵便番号）は、ハイフンを必要とする場合には、integer型ではなく、string型になる（確かに、ハイフンは数字じゃないや）phone_number（電話番号）は、string型でないと、「090」が「90」と保存されてしまう。（エクセルであるあるのやつだ！）また
phone_number（電話番号）に一意性制約をかけると１つの電話番号につき、１つの商品しか買えなくなるのでunique: trueは消す。（buysテーブルについて「商品購入時のデータ」ではなく「商品購入者」に近いニュアンスで捉えていたことに気付けた）itemsテーブルで
buy_idは外部キーカラムとして保存できないため削除する（確かに出品時は誰が買うかわからないのでitemに紐づくbuyのデータは無いや）itemsテーブルの
commission（手数料）とprofit（利益）はJavaScriptを使用してviewで値を表示する実装となり、DBに値を保存しないので不要。（アプリがPAYJPと利益がいくらなのかデータをやりとりする時に使わないのかなと思ったが、ここではあくまでお客様の手元にはいくら入るよ！とお知らせする役割なのかと理解。アプリへの利益は、アプリとPAYJPのやりとりの中で、価格の総額を元にPAYJPがもらう手数料を引いたアプリへ利益を別途計算すればいいのかと理解。）商品は「削除するアクション」があるから、itemsテーブルに
deleted_atを入れたが、そもそも、削除＝行ごと削除だった😱
感想
カリキュラム通りにやるのと、自分でコードを書いてみるのとでは、レビュアーをもらえるの嬉しさが格段に違うように感じた。
いざ、自分で書いてみるとどこまで書けばいいんだろうというのがわからないことに気づけた。
すごい楽しいんだけど気づいたら機能実装が終わる前に寝る時間になっていて、夕礼でnさんが言っていた「もっと時間がほしい」という意味を実感した。
