バリデーションとカラムオプションの違いについて

Question

閲覧ありがとうございます！

バリデーションとカラムオプションの役割の違いが分かりません。よろしくお願い致します。

前提

動物テーブル
動物名	string

動物名は、絶対に存在するとした場合、

##migration
create_tabe :animals |t|
  t.string :name, :null => false
end

##model
class Animal < ApplicationRecord
  validates :name, presence: true
end

マイグレーションとモデルの両方に記載できるかと思います。

疑問：モデルのバリデーションだけに条件を付せたらいいのでは？

• マイグレーションは、DBのスキーマ変更の役割を担うもの。（テーブル及びカラム）
• バリデーションは、レコードを作成、変更する際に働くもの（レコード）

とそれぞれの視点（担う役割）が異なる事は分かるのですが、最終的には手を加えたいレコードの動物名がnullでは無いことが分かればいいので、モデルだけに条件を付せばいいのでは？。。。。

生SQLを発行した場合、モデルだけでは対処できないので、DBスキームのオプションも必要になってくる？？？
モデルに条件を付すのは、新規登録、編集する際にエラーを出させるため？

よろしくお願いいたします！

Answer 1

マイグレーションは、DBのスキーマ変更の役割を担うもの。（テーブル及びカラム）

ということで、データベースを直接触る、他のシステムから接続する、Rails段階でのバグなどどんな操作をやってもNULLが入らない、というのがデータベースレベルで設定するメリットです。

うっかり条件を満たさないデータが混入してしまえば、後々のハンドリングで混乱するもととなりますので、新規作成時にDBレベルで制約をかけられるのであればかけておくことをおすすめします。

モデルに条件を付すのは、新規登録、編集する際にエラーを出させるため？

DBレベルのみの設定だった場合、そのまま投げてしまえばSQLエラーとなりますので、Railsでエラーをハンドリングするにはモデルレベルでのバリデーションが必要です。

Comments

[PartyKids]

今回も助けて頂き、ありがとうございます！

＞データベースレベルで設定
そういう事だったんですね！
マイグレーションは、DB自体の設定、バリデーションはDBにレコードを操作する際のフィルター的な役割をしており、違うんですね。

＞そのまま投げてしまえばSQLエラー
だから、カラムオプションを付与したら、バリデーション時点でエラーをキャッチ出来るように、モデルにも条件を付与して例外処理を実施する必要性が出てくるんですね。

ありがとうございました！