Ruby on Rails：在模型或数据库中validation会更好吗？

在模型或数据库定义中validation属性是否通常是更好的实践（以及为什么）？

对于（一个微不足道的）例子：

在用户模型中：

validates_presence_of :name

与迁移相比：

 t.string :name, :null => false

一方面，将其包含在数据库中看起来更能保证不会有任何types的不良数据被偷偷地进入。另一方面，将它包含在模型中使得事物更透明，更易于理解，其余的validation。我也考虑过这两种做法，但这看起来既不干又不可维护。

我强烈build议在两个地方都做。在模型中执行此操作可以节省数据库查询（可能通过networking），从而实质上会出错，并在数据库中执行此操作可确保数据一致性。

并且

 validates_presence_of :name

不一样的

 t.string :name, :null => false

如果你只是在数据库中设置NOT NULL列，你仍然可以插入空白值（“”）。如果你使用模型validates_presence_of – 你不能。

两者都是好的做法。模型validation是用户友好的，而数据库validation添加了一个最后的手段组件，它会加固您的代码，并显示您的应用程序逻辑中缺less的validation。

它有所不同。我认为应该在数据库中完成简单的与数据相关的validation（例如string长度，字段限制等）。任何遵循一些业务规则的validation都应在模型中完成。

我会推荐Migration Validators项目（ https://rubygems.org/gems/mv-core ）来定义db级别的validation，然后透明地将它提升到ActiveRecord模型。

例：

在迁移：

 def change create_table :posts do |t| t.string :title, length: 1..30 end end

在你的模型中：

 class Post < ActiveRecord::Base enforce_migration_validations end

结果你将有两个级别的数据validation。第一个将在db中实现（作为检查约束的触发条件），第二个作为模型中的ActiveModelvalidation。

取决于你的应用程序devise，如果你有一个小型或中等规模的应用程序，你可以在两个或只是在模型中做到这一点，但如果你有一个大的应用程序可能面向服务或分层，然后有基本的validation，即强制/可空，数据库中的最小/最大长度等，更严格的模式中的模式或业务规则。