マイグレーション データ型は何が適しての？？

#マイグレーションで実現できること

テーブル作成
テーブル削除
カラム追加
カラム名変更
カラムのデータ型変更
カラム削除

#マイグレーションファイル作成

マイグレーションファイルは モデルを作成した時 に一緒に作成される。
さらに マイグレーションファイル単体 で作成することも可能。

ターミナル

rails g model　[モデル名] [属性名:データ型 属性名:データ型・・・] [オプション]

#単体で生成する場合
rails g migration　マイグレーション名

上記のコマンドを実行することで、db/migrateフォルダの中にマイグレーションファイルが作成される。

#データ型は何が適してるの？？

オフィシャル情報	日本語でざっくり概要
primary_key	プライマリキー
string	文字列(1〜255文字)
text	長い文字列(1〜4294967296文字)
integer	整数(4バイト)
bigint	整数(8バイト)
float	浮動小数
decimal	精度の高い少数
numeric	数値
datetime	日時
time	時間
date	日付
binary	バイナリーデーター
boolean	Boolean型

##似ているけど違うものはどうするのか

文字を扱う場合、stringとtextどちらが適しているか

stringは、255文字までしか扱うことが出来ないため、状態や時期によっては、256文字以上になる可能性のあるデータを扱う場合はtextを使うことをおすすめします。
名前やメールアドレス、社名などの文字情報は、stringで取り扱い、本文や備考などの文章情報はtextを使うのが一般的です。

enumを扱う場合、stringとintegerどちらが適しているか
hashのintegerをマッピングできるのがenumなので、enumで扱う予定のカラムをstringにしたらそもそもenumを取り入れる意味がないし、機能しないですね。ということを冷静に考えて、enumで扱う予定のカラムのデータ型はintegerが適しています。

idを扱う場合、 integerとbigintどちらが適しているか
idは、将来的にユーザーが増えると膨大な桁数になる可能性があります。Rails5.1からidカラムがデフォルトでbigintになっていることも踏まえて、基本的にはbigintが適していると考えて良いでしょう。

いずれも、現状と一致させるという考え方よりは、将来的に「入らない！」という状況になる可能性が少しでもあれば大きめの箱を用意する、という考え方で選定すると安心です。

補足

######Rails modelの命名規約

Railsでは、modelに対応するデータベースのテーブル名はmembersのように複数形になります。

しかし、modelのクラス名は、Memberのように頭が大文字の単数形になる。

また、modelを作成する時は、「rails g model member」のようにmemberを小文字始めても大丈夫です。

また、例えばmember_imageと指定してもMemberImageとしても、MemberImageモデル(テーブル名はmember_images)が作成されます。

ただし、membersのように複数形にすることは厳禁です。Membersモデルが作成されてしまいます。modelは必ず単数形で作成しましょう。