DB設計手間取った件について
何事もなかったように更新してみます
TECH::EXPERT最終課題（４人でアジャイル開発）のタスクでDB設計をやったので
自分がやったことをつらつら書いてみる
そもそもDB設計って何やるんだっけ？
モデル、制約、アソシエーション、README、ER図作成、、、
モデル
モデルってどう考えればいいんだ、、ってなるんですけど
まず実装するアプリケーションの機能を考えて全て書き出す
例：LINE → ログイン、チャット、グループ作成、いいね機能、スタンプ購入とか
そしてその機能で必要そうな値を書く
例：ログインはユーザーの名前とパスワード
グループ作成はグループ名と参加してる人の名前とかとか
最初、DB設計は時間がかかってしまうのですが全然良いと思います！⇦必死
最終課題でメルカリのコピーサイトのDB設計を実際にやったのですが設計に４日
かけてしまい、チームの人には迷惑をかけました、、
実際、TECH::EXPERTのメンターさんもDB設計は慣れといっていましたし笑
どのテーブルになんのカラムを持たせるべきなのか非常に迷いました
なのでプログラミング学習を始めて間もない時は自分の感覚の話になってしまいますが機能ごとにモデルを作成するって考えた方がわかりやすいと思います。
ただ、ツリー構造（カテゴリー同士が繋がってる）のタグを検索するような複雑な機能はカラムの組み方もアソシエーションも難しめなので簡単なアプリ限定で考えた方が良いです。
あと注意点としてはモデル、カラム名に予約語を使うとエラーが起こるので使わないようにしましょう
予約語とは、MYSQL側で使用されるためテーブル名やカラム名に設定することができないよう決められている単語のことです
アソシエーション
アソシエーションは１対１とか、１対多とか、多対多とか自分が説明できることがないのでアソシエーションについての記事を貼るだけ貼って
モデルで自分が起こしたエラーを書こうと思います
まずモデルをrails g model モデル名で作成します
修正する為にモデル削除コマンドのrails d model モデル名を入力しました
するとファイルの中ではモデルとマイグレーションファイルが消えているのに
先ほどページを開いていたせいか未保存の状態で画面には残っていました
そこで未保存状態のままrake db:migrateのコマンドを打つと先ほど削除したはずのマイグレーションファイルが未保存のはずなのに反映されてしまいます、、、
これはもしかしたらATOM特有かもしれないです
なのでもし、モデルを削除した際は一度ファイルと画面上の２つを確認してから
rake db:migrateを押すといいかもしれません
--------------------------------------------------
reference先のテーブルがないとエラーが起きます
これは当たり前かもしれませんが、userテーブルを作成する前にuser_idを必要とする
テーブルを作成してしまうとマイグレーションのエラーが起きます
これは追加機能をどのようにするかも重要になり、もし追加したい機能のテーブルの
idを他のテーブルにもたせたい場合最悪一度マイグレーションファイルを作り直さなきゃいけなくなる可能性があります。
なので追加機能があらかじめわかっているのであれば変更しそうなテーブルは後の方に
作成した方がいい
最悪の最悪
rake db:migrateはマイグレーションファイルを上から読んでいく
ので！マイグレーションファイル名の数字を変えればファイルの位置が変わって読み込む順番も操作できる！！！
制約
モデルにかける制約ですが、一番良いのが正直よくわかりません、、
最初に１００％の制約をかけるのか、追加機能を作成するときに一緒に考えるのか
一番困ったのは、チーム４人で機能もバラバラに担当していたので最初どれくらいの制約をかけるのがベストなのかわかりませんでした。
なので結論、かけ過ぎず、かけな過ぎず、、笑
とにかく最低限の値はこれかな、、みたいな、、
ここは正直、個人で開発する時とチームで開発する時とで変わると思うので上手く
コミュニケーションをとってチームに合った制約の掛け方を見つけるべきだと思います
自分は何回もチームメイトに担当する機能のことを聞きまくってなるべく早く作ることを意識しました（結果、４日かかったけども、、）
ER図
そしていざER図作成！！
こんなんです
ちなみに自分が使ったアプリはMySQLWorkbench.appというアプリです
使い方をわかりきっていない自分でも上記のようなER図を作成できるしイメージがしやすかったのよかったです！
READMEに関してはコードレビューをしてもらう際、必ず目に付く箇所だし
マークダウンの練習にもなるので見やすさ重視で書きましょう（余裕あったら）
だいたいDB設計は以上です
あとは便利なコマンドをちょい説明して終わろうと思います
DB設計の時、モデルのカラムを編集したい、制約を変えたいって時があると思うのですがその場合追加するためのマイグレーションファイルを作成するのが正当法です
rails g migration Addカラム名To追加先テーブル名 追加するカラム名:型
で失敗したらrake db:rollbackしてやり直して、、、
前半のカリキュラムでこの壁にぶち当たり自分これでDBが嫌いになりました
そこで調べてるうちにrails db:migrate:resetというコマンドに出会い、
前までのDBへの苦手意識がなくなりました
このコマンドは一度全てのDBを削除してマイグレーションファイルを元に作成し直す
似たコマンドでrails db:resetというコマンドがあるが同様に全てのDBを削除してschema.rbのファイルを元に作成し直す
schema.rbはマイグレーションの記録的なもの
実際何に使うのかはこれで
なのでカラムや制約をちょこっと変更したい時は
rails db:migrate:reset
をするとDBもschemaファイルも更新できる
ただこのコマンドを打つとDBの中身が消えてしまうので消えても良い内容であるか
確認することともしくはseedファイルありきで実現可
ただやはり正当法は上記のマイグレーションファイルの追加して書く方らしいので
会社ではなく個人アプリ程度なら使えるコマンドです
是非試してみてください（１５０）
