ruby-on-rails - 在 Ruby on Rails 中使用迁移

Question

我想确认以下分析是正确的:

我正在 RoR 中构建网络应用程序。我为我的 postgres 数据库设计了一个数据结构(大约 70 个表；这个设计在开发过程中可能需要更改和添加以反射(reflect) Rails 的做事方式。例如，我设计了一些用户和角色表 - 但如果使用 Restful 有意义身份验证，我将删除它们并替换为 RA 需要的任何内容。)。

我有一个 shellscript，它调用一系列 .sql 文件来用表和初始数据(例如，Towns 预先填充了邮政城镇)以及测试数据(例如，Companies 得到一些虚拟数据)填充空数据库公司所以我有数据可以玩)。

例如:

CREATE TABLE towns (
  id         integer PRIMARY KEY DEFAULT nextval ('towns_seq'),
  county_id  integer REFERENCES counties ON DELETE RESTRICT ON UPDATE CASCADE,
  country_id integer REFERENCES countries ON DELETE RESTRICT ON UPDATE CASCADE NOT NULL,
  name       text    NOT NULL UNIQUE
);

提议 0:数据比应用程序持续时间更长，因此我确信我希望在数据库级别强制执行参照完整性以及在我的 RoR 模型中进行验证，尽管缺乏 DRYNESS。

提议 1:如果我用迁移替换脚本和 sql 文件，目前无法告诉我的 Postgres 数据库我当前在迁移代码中的 SQL DDL 文件中设置的外键和其他约束。

提议 2:迁移的吹捧好处是对架构的更改与 RoR 模型代码一起进行版本控制。但是，如果我将脚本和 .sql 文件保存在 railsapp/db 中，我可以同样轻松地对它们进行版本控制。

建议 3:鉴于迁移缺少我想要的功能，并提供了我可以复制的好处，我没有理由考虑使用它们。所以我应该在脚本/生成模型时--skipmigrations。

我的问题:如果命题 0 被接受，命题 1、2、3 是对还是错，为什么？

谢谢!

Answer 1

命题 1 至少在两种情况下是错误的——你可以使用像 foreign_key_migrations 这样的插件执行以下操作:

def self.up
  create_table :users do |t|
    t.column :department_id, :integer, :references => :departments
  end
end

这会在您的数据库中创建适当的外键约束。

当然，您可能还有其他想要在 DDL 中执行的操作，在这种情况下，第二种情况会变得更加引人注目:您不会被迫在迁移中使用 Ruby DSL。尝试使用 execute 方法:

def self.up
  execute 'YOUR SQL HERE'
end

有了它，您可以在迁移中保留 SQL 脚本的内容，获得后者的好处(最突出的是 down 方法，您在原始问题中没有解决)和保留您喜欢的较低级别的控制权。