Railsガイド +α メモず 【バリデーション】

はじめに

Active Record バリデーションを読んでわからなかったこと、メモです。

気になった見出しがあればご覧ください。

メモず

バリデーションの種類

モデルレベルでのバリデーション

Railsの基本的なバリデーション

データベース制約

メリット：複数のプログラミング言語を使用するプロジェクトであれば、大元であるデータベースレベルでバリデーションをすることは理にかなう。
デメリット：バリデーションのテストはアプリケーションと分離して行わねばならず、保守も困難になる可能性がある。

ストアドプロシージャ

SQL文をまとめて保存し、関数のように名前で呼び出す。
データベース制約の一種

クライアント側でのバリデーション

メリット：扱いやすい
デメリット：ユーザーによってバリデーションを変更されてしまうリスクがある。

コントローラレベルのバリデーション

メリット：手軽
デメリット：再利用性が低い、一貫性が欠如する、全体に散らばっているため維持・更新が困難。パフォーマンスのボトルネックになる、テストが複雑化する。

バリデーションをスキップするケース

以下のように、バリデーションをスキップするメソッドは大量にある。

バリデーションをスキップするなんてあるのか・・・？

バリデーションをスキップするメソッド

• decrement!
• decrement_counter
• increment!
• increment_counter
• insert
• insert!
• insert_all
• insert_all!
• toggle!
• touch
• touch_all
• update_all
• update_attribute
• update_column
• update_columns
• update_counters
• upsert
• upsert_all

例：ランダム生成された大量のテストデータ

大量のデータに、すべてバリデーションを適用することは時間コストがかかる。
同じコードで生成されたテストデータの場合、最初のいくつかを検証し、他はバリデーションをスキップすることで効率的にテストが行える。

例：管理者による操作

バリデーションは負荷がかかり、時間もかかる。そのため、正しいことが保証されるならバリデーションをスキップするのは合理的。

例：内部システム間のデータ交換

例：データの同期

例：リアルタイム処理・ストリーミングデータ

バリデーションによる負荷を嫌い、バリデーションを省略・簡略化することがある。