这很可能是一个菜鸟问题，因为人们使用这种宝石并且很多人喜欢它，但我不明白目的。我正在查看一个项目，它已在此处多次使用，例如t.references :foreign_key_table_name , :foreign_key => true,add_foreign_key :table :foreign_key_table_name, :options和 create t.foreign_key :foreign_key_table_name。希望那些没有混淆，因为它们脱离了上下文。
但是我不明白这与内置的railst.references :foreign_key_table_name或我只是添加的有什么不同t.integer :foreign_key_table_name_id？它是否只是通过明确这是一个“外键”来使其更具可读性？如果是这样的话，我可以添加评论而不是宝石......我看到的唯一优势是您可以将选项移动:dependent到迁移中而不是在模型中，但是谁在乎呢？
一些数据库引擎支持合法的外键约束：如果有人试图保存 aChild为parent_id5，但没有5，那么如果存在链接和的外键约束Parent，数据库本身（不是 Rails）将拒绝记录。idchildren.parent_idparents.id
外键还可以指定删除父项时会发生什么：例如，在 MySQL 中，我们可以删除或使依赖记录无效，就像 Rails 对 所做的那样:dependent，甚至直接拒绝删除并抛出错误。
由于并非所有数据库引擎都提供此功能，Rails 提供了模拟它的功能:dependent，并且在软件级别拥有它非常好，这样依赖的子记录可以destroy在删除父记录时触发它们的回调。由于该功能独立于引擎，因此几乎独立于模式，Rails 不处理外键的创建/删除。这就是发挥作用的地方foreigner：如果您的引擎支持外键约束，并且您希望对数据完整性更加自信，foreigner则可以提供帮助。
在这里复活一个老问题，但是……</p>
在 rails 内部，让 rails 强制执行这种关系很好。
但是，如果您的项目发展到拥有也可以从其他语言访问这些表的代码，则不会有 Rails 强制执行关系的好处。这些外键约束被烘焙到 SQL 表本身中，因此可以保护非 Rails 代码。
如果您需要执行数据修复或以其他方式通过本机 SQL 操作数据，这也将保护您。
另一个原因是某些 SQL 文档工具会查看数据库上的外键，因此拥有生成它们的 gem 很酷。Rails 4 添加了在创建表的同一迁移中定义外键的能力：
t.references :something, foreign_key: true
如果您使用该references类型，生成器将为您执行此操作。Rails 在像这样something_id使用时默认添加一个索引foreign_key