Rails 3 中的外键

Question

我了解Rails的理念认为数据完整性检查应该在应用程序级别而不是数据库级别进行。像许多其他开发人员一样，我非常不同意。

我发现了很多关于这个问题的讨论，但它们似乎都过时了，并且令人沮丧的是，它们似乎指向了不同的解决方案。

我想象中，在Rails 3中有一种事实标准的处理外键约束的方式。然而，无论它是什么（如果它确实存在），似乎都被所有过去的讨论所淹没，因为我找不到它。

截至目前，Rails开发人员是否大多对外键约束达成共识？如果是这样，我很想知道它们通常是如何处理的。

- Jason Swett

Answer 1

出于这个原因，我（以及编写《企业级Rails》的人们 - http://oreilly.com/catalog/9780596515201）建议您在SQL中编写整个上下迁移。

优点如下：

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

缺点如下：

• 它不是数据库通用的（谁在乎，你会多频繁地更改数据库？）
• 它不是Ruby（但每个好的Rails开发人员都应该知道SQL，对吧？）

但总的来说，我认为优点大于缺点。

快速示例：

  def self.up
    execute <<EOS

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

EOS
   end

- Omar Qureshi

---

不错的答案。我能否建议使用<<-EOS形式的heredoc呢？这样你就不需要将所有内容对齐到第0列了。 - noodl

没错，那也是完全合理的 - 不过 - 我有点怪异，喜欢确保我的 SQL 对齐 - 特别是如果在同一次迁移中编写了几个函数/触发器。 - Omar Qureshi

我认为这就是我要做的事情。只是出于好奇，这是否意味着我不能一次性生成我的表格和模型？我是否需要在SQL中编写我的表格定义，然后单独创建一个匹配的模型？ - Jason Swett

你可以使用Rails g model Foo命令，然后删除create_table :foo这一部分。 - Omar Qureshi

Answer 2

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

尽管Active Record没有提供直接处理此类功能的工具，但可以使用execute方法来执行任意SQL。还有许多插件，例如foreign_key_migrations，可将外键支持添加到Active Record中。

- Heikki

Answer 3

前几天我也问了同样的问题，所以我做了一些研究，并将我的发现整理在一个较旧但类似的Stack Overflow问题的答案中。希望对你有用。

顺便说一下，当你说你“热情地反对”数据完整性检查应该在应用程序级别而不是数据库级别进行时，我想你的意思是它们应该在两个级别进行，而不仅仅是在数据库中。我希望我正确地认为几乎每个人都同意在应用程序级别进行完整性检查是一件好事，唯一争论的话题是它们是否应该另外在数据库中进行。

- Adam Spiers