database - Laravel 4.x 生产环境迁移

Question

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

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

2. 出于类似的考虑，我们的大多数播种机都以“delete()”开始，基本上是在运行之前删除表中的所有数据，我对在生产环境中运行 db:seed 和文件毫无兴趣我们目前有。

3. 我在他使用的系统中看不到任何区分生产环境和其他环境的信息，因此我们不会执行诸如删除表等操作。

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

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

所以归结为一个问题:我是否遗漏了一些 re:mifrations(从 DBA 的角度看如何在生产环境中使用迁移/播种器的文档)，或者我应该自己使用 .sql 文件管理模式？我在网上看到的大多数例子都掩盖了这样的生产问题，我不愿意让我的数据处于危险之中。

Answer 1

...most of the migrations he's written have an up() and no down()...

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

Of similar concern, most of our seeders start with "delete()" basically deleting all data in the table prior to running, there's no way I'm interesting in running db:seed on production, with the files we currently have.

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

I see nothing in the system that he's using that differentiates between production and other environments so we don't do things like drop tables, etc.

Laravel 有一个环境检测系统 - see here for more info .如果你想根据你的环境播种 - 你可以在 DatabaseSeeder.php 中做这样的事情:

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

...the apps DB user does not have permissions to create/drop tables, and can only insert and delete, preventing the accidental dropping of tables

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