データベース設計

[manabu-ouchi]

"# 実装概要

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

実装方針

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

実装条件

• [ ] 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設計の方針を立てよう」 "