Rails中的外键通常是否可以避免？
Rails无法在迁移中创建外键（但是有插件可以执行此操作）。 例如，还有许多级联选项，因此您可以获得级联删除。
内置了所有这些选项后，是否值得在数据库中创建外键？ 这是Rails开发人员通常会避免的事情或者是什么？ 您认为如果推荐的做法是Rails会原生支持它。
这是一个神圣的问题，因为DHH（Rails的创建者）之前已经说过他将数据库视为一个巨大的哈希表，因此利用数据库引擎擅长的一些function，通过使用诸如约束或存储过程不被认为是Rails纯粹主义者的Rails Way。
也就是说，如果您希望强制最接近数据的数据的完整性，或者您的数据库由其他应用程序共享，那么请务必使用其中一个插件来创建外键。 毕竟，它有什么害处，对吧？
刚刚加入John Topley的回答，我做了一些研究，发现了一些DHH关于这个主题的想法，这些想法引起了一个有趣的读物：
- （2006年6月） DHH回复 Teflon Ted的博客文章我们应该喝DHH的Kool-Aid吗？
- （2006年2月） DHH在评论中回答 （搜索“好咆哮”）某人对Rails的咆哮
- （2006年5月） DHH回复某人的迁移请求以支持外键
- （2006年1月） DHH解释了为什么模型关联不属于schema.rb
我找不到DHH将数据库称为“巨型哈希”，所以约翰可能会引用不同的引用。 我很想阅读DHH最新版本的观点。
在过去的几年里，我没有发现其他人的太多意见。 以下是我发现的：
- （2011年7月） CodeGenesys解释了为什么以及如何在Rails中使用外键
- （2008年1月）一篇题为你应该在Rails中使用外键约束的博客文章
- （2007年11月） 一篇有用的博文，其中包含对外键优缺点的更多有用研究
Rails不会阻止您在数据库中使用外键约束，它默认情况下不会将它们提供给您。 “Rails方式”依赖于Rails来管理数据库，级联删除，强制引用完整性等。
有几个插件可以为迁移添加外键约束，但我通常会选择手动添加它们。 假设您已创建CreateUsers和CreatePosts迁移，您可以添加“LinkPostsToUsers”迁移：
# Assumes PostgreSQL class LinkPostsToUsers < ActiveRecord::Migration def self.up execute " ALTER TABLE posts ADD CONSTRAINT fk_posts_user_id FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE ON UPDATE CASCADE" end def self.down execute "ALTER TABLE posts DROP CONSTRAINT fk_posts_user_id" end end