0

我正在开始一个新的 Rails 项目，我想知道当涉及到数据库时我应该做什么。我应该跳过使用迁移并将数据库脚本与 Rails 项目分开，还是应该使用迁移？通过“手动”创建数据库，您不会获得更好的控制吗？那应该怎么做？

4

5 回答 5

2

数据库的创建应该通过 Rails 完成，因为它几乎可以为您的每个环境完成所有设置。

至于迁移，Rails 核心团队非常努力地使迁移与从 postgresql 到 mysql 甚至 oracle 的所有不同数据库兼容。虽然通过迁移可以比创建自己的表更轻松地完成许多操作，但它们仍然为您提供了将自己的 SQL 添加到组合中的灵活性。

看看我为 postgresql 数据库创建 HSTORE 扩展的迁移。

class SetupHstore < ActiveRecord::Migration
  def up
    execute "CREATE EXTENSION IF NOT EXISTS hstore;"
  end

  def down
    execute "DROP EXTENSION IF EXISTS hstore;"
  end
end

这意味着您几乎可以从迁移中执行任何您想要的命令。请注意，使用 Rails 迁移可以让您灵活地回滚迁移，方法是添加一个 up 和 down 方法来恢复迁移。您可以在迁移中做很多巧妙的事情。

此外，rails 还为您提供了将迁移转储为 Ruby 或 SQL 的选项，用于诸如 HSTORE 之类的无法使用 Ruby 实现的事情。此选项位于application.rb配置下的文件下。

最后，如果你打算使用 Rails，你不妨使用它提供的所有东西来简化你的开发。

在手动创建数据库之前，您应该阅读有关 Rails 迁移的指南，以便对它们有更多的了解。

Rails 迁移

于 2013-01-18T14:10:06.120 回答
1

我认为你应该使用迁移。他们确保您的代码和数据库“同步”，并且您不会尝试在旧表上运行代码。

例如，当您将应用程序的新版本部署到生产环境并且不使用迁移时，您必须在数据库上执行两次工作：在开发和生产环境中。并让有一个登台环境，甚至更多的工作。

另一个好处是，通过迁移，您可以快速将您的开发数据库“转换”到较旧的阶段（在我的情况下，我不时需要此功能）。

或者，如果它适用于您的项目，请使用像 MongoDB 这样的无模式数据库。在那里，您可以在代码中定义模型，而不必担心迁移。但是在生产时要小心：也许您必须将数据从一列迁移到另一列；）

于 2013-01-18T14:00:50.423 回答
1

从 Rails 的角度来看，手动创建数据库迁移文件并不是一个好主意。就像您拥有一个具有很多功能的 gem，然后您正在实现自己的逻辑，提供与 gem 相同的功能。

如果您稍后进行任何更新，这不仅会消耗时间，而且可能会在迁移版本控制和模式加载方面产生问题。

诀窍是通过以下命令快速创建迁移、脚手架：

rails g scaffold scaffold_name index create name:string

这将根据您在命令行中提供的内容创建脚手架，就像上面一样，将使用scaffold_name和创建两个方法index和 create一个字段name作为字符串创建脚手架。

同样，您可以使用迁移添加具有单个命令行的列：

   rails g migration add_field_name_to_table_name email:string

或者删除不需要迁移的列：

rails g migration remove_field_name_from_table_name email:string

您甚至可以通过以下方式将迁移回滚到前一个：

rake db:rollback会让你后退一步

您可以通过以下方式迁移到任何版本：

rake db:migrate VERSION = "434483468726583"其中“434483468726583”是要切换到的迁移版本号。

就像这样，有许多命令可以与rails migrations一起使用。

总而言之，无论您想要什么迁移，您都可以轻松获得命令。

于 2013-01-18T14:03:15.120 回答
1

迁移是为了替换数据库脚本。因为它们更易于管理并且可以互操作。在进一步配置数据库时，您可以将代码添加到您独立管理的脚本中，但这仅在您想要针对您正在使用的数据库系统执行特定操作且迁移不涵盖这些情况时才有用。

于 2013-01-18T14:06:12.410 回答
1

Rails 迁移是改变数据库结构的任务——也就是说，它们会改变你的模式。迁移非常适合强制执行关系数据库的底层结构，并且是在开始和与其他人一起工作时使用的好主意；但是，请注意存在许多限制和缺点。例如，当您在模型中创建验证时，有时这些验证不会在数据库级别强制执行，从而使数据完整性仅在应用程序级别维护。

随着时间的推移，随着应用程序和产品（业务逻辑）的发展，您将对模型进行大量更改。鉴于迁移是通过时间戳跟踪的，因此在一个相对较大的团队中工作时，强制在正确的时间以正确的顺序将迁移应用到生产中可能会变得非常棘手。

非关系型数据库，例如 MongoDB，通过允许一定的模式灵活性来支持模型演化。例如，如果您想向模型添加一个字段，您可以简单地开始在该字段中保存数据，而不必运行迁移来更改数据库结构。大多数人说 MongoDB 是“无模式的”，但更准确的说法是 MongoDB 允许“模式灵活性”。查看Mongoid gem 以使用 MongoDB 定义模型。如果您的应用程序将是探索性的并且随着时间的推移可能会发生很大变化，那么使用 MongoDB 和 Mongoid 可能是值得的。

于 2013-01-18T16:50:16.733 回答