DHHが考えるRailsのバリデーション設計

3行まとめ 単純なバリデーション（必須・範囲・文字数など）はHTMLとDB制約、CHECK制約があれば十分であるというのが最近のDHHの主張。 SQLiteではCHECK制約が少し貧弱なため、制約変更の可能性がある場合は従来通りアプリケーションでもバリデーションした方がいい。 Rails初心者はDHHの方法をそのまま採用するのはやめた方が良い。 調べたきっかけ 最近DHHがonce.comでのCampfireをはじめとしたプロダクトで、NULL制約やDB制約で防げるようなRailsのモデルのバリデーションを積極的には利用しないでいるという主張をしている。 DHHの主張を要約すると以下のようになる。[1] HTMLでのバリデーションが優れている 例えば、input type=“email” にしておくとブラウザで勝手にメールアドレス形式ではない場合にエラーにしてデータ送信をしないようにしてく

[YassLab]

"SQLiteについてはRailsもSQLiteのプロダクション利用も積極的に勧めていきたい側面もあるし、MySQL等に比べるとCHECK制約の機能が少し貧弱な側面もある / 不安ならアプリケーションのバリデーションをサボるのはお勧めしない"

[daaaaaai]

ユーザへのバリデーション失敗メッセージ通知にも足りるんだろうか。

[hogeaegxa]

テーブル上の正しい値と不正な値の定義が呼び元でコロコロ変わるなんてありえないし、じゃあDBに書く値のチェックはDBでやるのがDRYじゃね？ってのはまあそう。表現力が上がってきたなら考えてみても良さそう

[wwolf]

cURLとかでリクエスト送ったらDBまでスッと到達しちゃうの怖いと思うの

[ledsun]

“入力が必須（required）、最低・最大入力文字数（minLength, maxLength）、数値の入力範囲（min, max）の用途であれば確かにRailsでのバリデーションは要らないなという感想。”

[magnoliak]

ちゃんと考えようねっていう話なんだよね