2

我是一位经验丰富的 DBA，对 Laravel 不是很熟悉。我的主要开发人员在 Laravel 方面经验丰富，但是，倾向于掩盖数据库细节。手头的问题是我们一直在使用工匠使用“迁移”和“播种者”。这在开发环境中运行得相对较好（有一些小问题）。我们的产品现已推出初始版本，现已投入生产。关注点：

  1. 开发人员创建了许多迁移，我对这些迁移在生产中的陷阱知之甚少。例如：他编写的大多数迁移都有 up() 和没有 down()。由于系统很小，通常的做法是每次都重置整个数据库并重新加载所有迁移和播种器 - 显然我们不能在生产环境中这样做，所以我担心只运行“laravel migrate”系统充满了实时数据。

  2. 类似的问题，我们的大多数播种机都以“delete()”开始，基本上在运行之前删除表中的所有数据，我对在生产环境中运行 db:seed 以及我们目前拥有的文件没有任何兴趣。

  3. 我在他使用的系统中看不到任何东西可以区分生产环境和其他环境，所以我们不做诸如删除表之类的事情。

  4. 我设置数据库的正常方式是有一个“受限”的应用程序用户，即应用程序数据库用户没有创建/删除表的权限，只能插入和删除，防止意外删除表。看来我必须拥有完整的数据库权限才能运行迁移和播种程序，并且相同的数据库连接文件（和嵌入式用户名/密码）用于应用程序和模式生成，我宁愿拥有出于安全原因，一个 DBA 用户和一个 APP 用户。

我们的模式相对简单，只有大约 30 个表，而且我很容易管理它，特别是因为 laravel 的模式构建器不支持许多 postgres 功能（json 数据类型、全文索引等），而且我们'不断地执行 db::raw() 命令来创建我们的索引，初始设置我们的序列值等。

因此，将其归结为一个问题：我是否遗漏了一些东西 re:mifrations（从 DBA 的角度来看如何在生产环境中使用迁移/播种器的文档），还是我应该自己使用 .sql 文件管理架构？我在网上看到的大多数例子都掩盖了这样的生产问题，我不愿意让我的数据处于危险之中。

4

1 回答 1

4

...他写的大多数迁移都有一个 up() 而没有 down()...

那不是进行迁移的方法。他非常懒惰（或者只是很糟糕）。迁移应该是两种方式。这样，如果有人出错，您可以“回滚”。因此down()，无论您up()是什么，都应该始终匹配。

类似的问题，我们的大多数播种机都以“delete()”开始，基本上在运行之前删除表中的所有数据，我对在生产环境中运行 db:seed 以及我们目前拥有的文件没有任何兴趣。

再一次 - 不是正常的方法。你应该只是“播种”你所拥有的。

我在他使用的系统中看不到任何东西可以区分生产环境和其他环境，所以我们不做诸如删除表之类的事情。

Laravel 有一个环境检测系统——查看这里了解更多信息。如果您想根据您的环境播种 - 您可以在以下范围内执行以下操作DatabaseSeeder.php：

if( App::environment() === 'dev' )
{
    $this->call('UserTableSeeder');
}

...apps DB用户没有创建/删除表的权限，只能插入和删除，防止意外删除表

您可以这样做并自己“创建”表，然后运行仅在表中插入/删除列的迁移。

于 2014-06-06T16:35:42.683 回答