テーブル定義書(2021.8.14 チーム開発)

uniqueキーの設計の仕方

• uniqueキー付与の対象：mail、（商品）
• マイグレーションファイルで命令する必要あり
• データベース上でのバリデーションみたいなもの
• 商品名につけるときは理由も一緒に提出！！
• とりあえず今回はemail　以外のuniqueキーは設定しない（余裕があれば後日・・・）
  ※deviseを使用したらindexとuniqueキーがmailに自動に付与される

indexの付与

• インデックスの付け方：１個以上あってもいい？→OK！！
• マイグレーションファイルにindexを付与するという命令を書き込む
• データベースへの格納の仕方が違う
• デメリット：検索は早いが、追加更新が多いと処理が遅くなる
• よく検索を行う部分に処理が重くなってきたら後から追加することも多い（ﾊﾟﾌｫｰﾏﾝｽ改善）
  ※deviseを使用したらindexとuniqueキーがmailに自動に付与される

AUTO_INCREMENTについて

テーブルごとに 1 つのカラムにしか設定できない？
→制限はない。Railsでは自動作成されるID部分に自動付与できるので◯するだけで良い

ネストの考え方

ordered_items、cart_items　のルーティングをorderやitemsにネストさせるか否か
→どちらでもよい
　ネストしなくて良いならそちらの方がシンプル

ER図とテーブル定義書の違い(2021.8.15)

ER図

• 依頼主に提示するために機能の連携のさせ方などを中心に考える
• テーブルの関係が視覚的にわかる

テーブル定義書

• プログラマー（製作側）が実装を行うための情報をインプット
• 詳細を説明

---

依頼側、製作側などの違いは特にない
慣習上分けているが、混同して作成される場合もある

ユーザー情報のカラム作成方法(2021.8.16)

姓名のカラムの作成

姓と名を別々に入力させて、保存する前に結合する

住所カラムの作成

【Rails】jpostalとjp_prefectureを用いて住所自動入力の実装

---

→これらはまったく別のカラムとして登録すればいい。
　結合させてカラムに保存させる必要はない。
　「def 　full_name ' a'+'b'　end」のような形式で結合表示できる
　※検索ワード：カラムを結合させる