データベース設計

[Onthevillage]

"# 実装概要

• フリーマーケットサイトを再現するために必要な、データベースの設計を行う。
• ER図を描画した後、READMEに設計情報を記述し、コードレビューを依頼する。LGTMが出たら完了とする。
• 以下の機能の実装条件を確認し、データベース設計を行うこと。 ・ユーザー管理機能 ・商品出品機能 ・商品購入機能

実装方針

• ブランチを作成する。
• フリマアプリの機能を考え、必要なテーブル・カラム情報を洗い出す。
• ER図を書く。
• READMEにデータベース設計を記述する。
• プルリクエストを作成してメンターにレビューを依頼する。
• LGTMをもらい、マージをする。

実装条件

• [x] ER図作成ツールを使用してER図を作成すること。

補足情報

• データベース設計を行う際は、以下のカリキュラムを参考にする。 最終課題補足カリキュラム Lesson1 「DB設計の方針を立てよう」
• 予約語については以下のカリキュラムを参考にする。 最終課題補足カリキュラム Lesson2 「データベース設計」

注意事項

• メンターにコードレビューを依頼すること。
• プルリクエストには、ER図を添付すること（Gyazoで撮影し、URLを記載しましょう）。
• データベース設計のコードレビュー最中にREADMEを修正する場合は、都度最新のER図をプルリクエストに添付すること。
• プルリクエストには、「What」と「Why」を記述すること（「What」と「Why」の記載されていないレビューは対応しません。実際の開発現場でも同様の対応であるためです）。
• LGTMが出るまでマージしないこと。
• 必須機能以外のテーブルに関しては、コードレビューの対象とはならない（必須機能では使用しないコメント用のテーブルなどがある場合、そこに対するメンターからの指摘は入りません）。
• 実装段階で仕様が変更された場合や、機能を追加する際に、テーブルやカラムに変更修正が生じることがある。その場合は、都度ER図やREADMEを更新すること（変更に伴うメンターへのコードレビューは不要です）。
• テーブルの作成は、そのテーブルが必要となる機能実装時に作成すること。不要なテーブルを作成してしまうと、修正が発生した場合の対応が困難になるため（例：ユーザー管理機能の実装時には、ユーザー管理機能に必要なテーブルのみを作成する。商品用のテーブルなどは作成しない）。
• LGTMが出る前に他の実装へ着手することは、推奨しない（Gitにおける複雑なコンフリクト等を引き起こす可能性があるためです）。

参考カリキュラム

• データベース設計とは何か・外部キーの設定 応用カリキュラム Lesson3 「設計をしよう」

• 中間テーブルの考え方・外部キーの設定 応用カリキュラム Lesson6 「ChatAppのDB設計をしよう」

• FURIMAのDB設計概要 最終課題補足カリキュラム Lesson1 「DB設計の方針を立てよう」 "

[Onthevillage]

【データベース設計 #3】 
■何を実装しないといけないのか？ ・データベース設計を記述したREADMEファイル


■計画 ・ER図作成ツールを使用し、ER図を作成
 ・READMEファイル
へ記述

■課題 ・「ユーザー管理機能」を適切に認識する ・「商品出品機能」を適切に認識する ・「商品購入機能」を適切に認識する ・READMEファイルに記述すべき全ての情報を洗い出す

■メンターの方からのアドバイス ・READMEファイルはあくまでもマイグレーションファイルに書き写す程度の情報量を記載する →ひらがな・カタカナなどをブロックするものもあるが、それは書き過ぎで時間がかかるため

[Onthevillage]

【最終課題補足カリキュラム〜DB設計の方針を立てよう〜】 https://master.tech-camp.in/v2/curriculums/6768

【ER図作成手順】 ①テーブル毎にエンティティを洗い出す ②関連付けを考える（アソシエーション） ③関連付けが完了したら外部キーを考える →ポイントは「多」の方を考える。「多」の方に外部キーを設定するため。

【知識】 has_oneメソッド →1対1の関係でどちらが親となるか →子は親が存在しないと存在できない 例：ユーザーとプロフィール

【実装ポイント】 ■必要なテーブル ①users ②items 必要なカラム：商品名、カテゴリー、値段、出品者

■その他必要な？エンティティ ①購入者②配送先 →itemsテーブルに入れてはいけない →has_oneを用いることになる → Furimaにおいて、購入のログは別エンティティに保存すること