Codecabulary Home / Learn Rails / Active Record Referential Integrity
"Garbage in, garbage out." -Ruby Buddha
Data is the backbone of your application. Allow a user to enter bad data, and you've crippled yourself.
Data can be validated in a number of locations:
- In the model. When Rails receives the form from the user, and before it passes it to the database, it can perform its own validations. Validations in the model layer can be very robust.
- In the controller. If you're coming from another object-oriented language, you may be tempted to perform validations in the controller. Ruby Buddha also advises to keep controllers skinny. Controller validations just ain't the Rails way.
- In the database. Database validations are called _database constraints because they literally control what can and cannot be entered into the database. They should be your last line of defense against bad data.
The Rails Way of Performing Validations
Active Record (one of two modules that makes up the Rails model layer) claims that validation intelligence belongs in your models, not in the database. As such, features such as triggers or foreign key constraints, which push some of that intelligence back into the database, are not widely used.
Like anything which operates at the application level, these cannot guarantee referential integrity and so some people augment them with foreign key constraints in the database.
Although Active Record does not provide any tools for working directly with such features, the execute method can be used to execute arbitrary SQL. You could also use some plugin like foreigner which adds foreign key support to Active Record (including support for dumping foreign keys in db/schema.rb).