Rails中的外键3

Question

据我所知，根据Rails哲学，数据完整性检查应该在应用程序级别而不是数据库级别完成。像许多其他开发人员一样，我非常不同意。

我已经找到了很多解决这个问题的讨论，但它们似乎都很老了，令人沮丧的是，它们似乎指向了不同的解决方案。

我必须想象在Rails 3中有一个事实上的标准方法来做外键约束。然而，无论它是什么（如果它确实存在）似乎被所有过去的讨论所扼杀，因为我找不到它

此时Rails开发人员是否大多与外键在同一页面上？如果是这样，我很想知道他们是如何处理的。

Answer 1

正是出于这个原因，我（以及编写Enterprise Rails的人 - http://oreilly.com/catalog/9780596515201）建议您在SQL中编写完整的上下迁移。

优点是：

• 在创建表时添加外键的能力 - 没有单独的alter table
• 它允许您使用特定于数据库的字段类型 - 例如tsvectors
• 它允许您添加不同类型的索引 - 例如Gin或Gist
• 它允许您编写函数和/或触发器
• 您不必记住DSL类型与SQL字段类型的关系 - 例如：编号

有缺点：

• 这不是数据库不可知的（谁关心以及您多久更换一次数据库？）
• 这不是Ruby（但每个优秀的Rails开发人员都应该知道SQL，对吗？）

但总的来说，我认为优点胜过劣势。

快速举例：

  def self.up
    execute <<EOS

create table .... (
  ....
);

EOS
   end

Answer 2

http://guides.rubyonrails.org/migrations.html#active-record-and-referential-integrity

“尽管Active Record没有提供任何直接使用这些功能的工具，但execute方法可用于执行任意SQL。还有一些插件，例如foreign_key_migrations，它们为Active Record添加了外键支持。”

Answer 3

前几天我发现自己也在问同一个问题，所以我做了一些研究，并在an answer to an older but similar Stack Overflow question中整理了我的发现。我希望这是有用的。

顺便说一下，当你说你“热心地不同意”数据完整性检查应该在应用程序级别而不是数据库级别完成时，我认为你的意思是他们应该在两者上完成级别，而不仅仅是在数据库中。我希望我认为几乎每个人都同意在应用程序级别进行完整性检查是一件好事，并且唯一有争议的话题是他们是否应该在数据库中进行。