在Rails数据库迁移期间截断表是否有风险?

时间:2015-06-01 17:58:06

标签: mysql ruby-on-rails activerecord

我正在添加一个向MySQL表添加唯一索引的迁移。是否存在截断表中任何现有数据的真正风险,因此可以添加唯一索引,因为表中的现有数据可能不是唯一的?

值得一提的是,此应用程序仍在开发中,尚未发布,因此我们不会丢失任何真实的用户数据。

任何人都可以想出一个真实世界的场景,我们可能会丢失重要的数据吗?

迁移的代码示例:

class AddUniqueIndexToFooOnBarAndBaz < ActiveRecord::Migration
  def up
    ActiveRecord::Base.connection.execute("TRUNCATE foo")
    add_index :foo, [:bar_id, :baz_id], unique: true
  end

  def down
    remove_index :foo, [:bar_id, :baz_id]
  end
end

2 个答案:

答案 0 :(得分:1)

tl; dr-你不会真的伤害任何东西,但不管怎么说都不要那么干扰。做一个db:reset

编写迁移时会发生的情况是db/schema.rb文件发生更改,其版本设置为上次运行的迁移的时间戳。存在迁移文件,以便:

  1. 使用有意义的DSL,您可以拥有能够证明数据库随时间发生变化的具体文件。
  2. 如果您在开发过程中发现某些错误(不要回滚生产数据库,只需编写新的迁移),则可以半任意地将更改回滚到数据库。
  3. 这意味着迁移文件应显示您正在对数据库执行的操作,并且TRUNCATE实际上并不是您对数据库执行的操作,而是您对数据执行的操作 。如果使用已经迁移的模式部署新环境,它将不会破坏任何内容并且SQL代码段将无法运行,但对于已经启动的任何环境,它将会运行。这有点奇怪,绝对没必要。

    详情

    在环境中首次部署应用时会发生什么?您应该(应该)运行rake db:create db:schema:load db:seedrake db:setup(它只是运行到其他命令)。 db:schema:load只是将您的schema.rb文件转换为实际的数据库架构,包含表格和索引以及所有有趣的内容。运行迁移后,架构文件将包含您想要的索引。然后,无论何时部署到生产环境,在添加任何数据之前,您的数据库看起来都是开箱即用的。

    在开发过程中,您不应该附加到数据库中的任何数据 - 它是测试数据,不重要和短暂的。你不应该感觉不好擦拭它,特别是如果你因为现有数据可能无效/重复而截断。

答案 1 :(得分:0)

无论是否使用rails迁移,截断表都会产生影响。更好的问题是询问截断表格是否存在风险,期限。

由于您尚未投入生产,因此不存在影响“真实”人员的风险,但您必须考虑的是如何截断表格会影响您的数据完整性以及如何作为开发人员,您将从任何问题中恢复你可能会遇到。

例如,如果您要截断的数据位于连接其他两个表的连接表中,那么您已经丢失了两个表之间的关系,并且基本上使您的数据中有很大一部分无用。但是,如果数据在一个无关紧要的表中,则影响要小得多。

简而言之,是的,存在风险,但回答这种风险水平的最佳人选是你。