As a database guy working in a Rails shop, I have huge qualms with "DRY". It encourages people to encode relationships in their models, and trust that's somehow magically going to keep their data sane. It's not. Believe me, it's not.
If you're using an RDBMS, use it. The model is just a representation of the data's canonical, authoritative state, which is what it looks like when it's been committed to the DB. The only way to keep your data sane is with Foreign Keys enforcing referential integrity between tables, and the only way to do that is to specify the relationship in both your models, and in your migrations.
Blind, slavish adherence to a pithy acronym is just going to get you into trouble.
The DRY ideal in this case would be more about describing the relationship only once, and having that relationship then propagate everywhere it needs to, most especially to the foreign keys in your database schema.
Sometimes, reaching that ideal is not practical and in the name of pragmatism a programmer will indeed repeat themselves. But that repetition is where the trouble starts. If you have to describe a relationship twice, then sooner or later someone is going to forget to update one place or the other. As a database guy, you would like them to always remember to update the place that tells the database about that relationship. But in reality, it may be just as likely that someone will update the model and forget to update the database.
The idea with DRY is that you should try very hard to find a way to represent the relationship only once so that mistakes can't happen, but that doesn't mean sacrificing the integrity of your data to do so.
That said, I know little about Rails, and perhaps it's hard to do it right, or at least easy to do it wrong.
Wait a sec, just because someone misused a term like "DRY" doesn't mean the principle is wrong. Re-representing data models in other execution environments is indeed a repetition - it just normally isn't identified as one, for some reason.
Adding a database field often has repercussions throughout the stack (not to mention throughout the rest of the system).
What's really interesting is to realize that DRY is traditionally only applied to static code, rather than runtime state. But personally I think it should apply to both.
The entire concept of database normalization is just a manifestation of DRY. Foreign keys exist so you don't repeat yourself by duplicating the same data in two databases.
Interesting parallel, but I'm not sure it's a good analogy with the typical DRY advice for writing code. In the real world, database normalization isn't automatically the right answer, and there can be valid reasons for repeating yourself.
Then again, there can be valid reasons for repeating yourself when writing code as well. Personally, I prefer "don't repeat yourself without a clear reason for doing so", which is a very different guideline.
"Don't repeat yourself without a clear reason for doing so" isn't really different at all from what most people mean when they say, "DRY". It's just removed from the ultra-literalistic interpretive context that too many Internet commentators apply to admonitions and guidelines of all sorts.
No developer who says, "DRY" actually means, "Never, ever repeat yourself." No developer who offers advice of any kind expects that it applies under all circumstances. We still phrase it in strict, prescriptive terms because it retains more of its moral force that way.
Anyone who expects pithy development advice to note exceptions is interpreting it in a juvenile way.
I'm afraid our experience is very different. I find the programming world to be full of people who will interpret guidelines like DRY with almost religious dogmatism, particularly if anyone Internet famous can be cited as the source.
Having been a mentor to many younger and less experienced programmers when they started working professionally, I have been the guy who had to clear up their absolute, literal belief in these sayings. Some people will quickly understand and accept that the world isn't as black and white as perhaps their CS course/favourite blogger/previous boss said or that they have taken rules of thumb too literally. Some never really do understand that, and their code reflects their lack of understanding and often looks like it was written to comply with every saying under the sun as its primary goal.
If you're using an RDBMS, use it. The model is just a representation of the data's canonical, authoritative state, which is what it looks like when it's been committed to the DB. The only way to keep your data sane is with Foreign Keys enforcing referential integrity between tables, and the only way to do that is to specify the relationship in both your models, and in your migrations.
Blind, slavish adherence to a pithy acronym is just going to get you into trouble.