是否有用于非常早期开发阶段的替代迁移工作流程。拉拉维尔

Question

我的推理，不感兴趣的可以跳到下面

我了解迁移的一般过程如何工作以及它们的用途，并且很高兴以预期的方式使用它们，即在整个应用程序生命周期中根据需要添加和删除字段。

我的疑问是，在项目开始时，我很少知道给定表中需要的许多字段，而在项目的早期阶段，我想设置主要功能和关系，并且也许只是在客户下定决心之前使用一些无用的字段。

底线是它伤害了我的强迫症，因为我知道那里有额外的迁移文件，可能看起来不像项目的 v1.0...一旦我在 v0.5，我可能会决定我已经足够远，可以开始正确管理迁移。

这是我的想法，但问题是：

在项目的早期阶段，在无需担心数据丢失或回滚的情况下，一次又一次地重复使用相同迁移脚本的最简洁步骤是什么。

只是补充一点，我不想刷新整个迁移，因为我真的更愿意保留我正在玩的任何数据，尤其是用于保持登录到后端等的用户表。

这样做会不会错：

我可以只删除表中的迁移行，然后运行迁移吗？

感觉这会产生副作用，并且可能会导致回滚，是这样吗？迁移表起什么作用，因为这似乎在实践中有效？

结束语

请记住，这只是我试图理解的一个概念。如果这是绝对不好的做法，我可以接受它！

Answer 1

编辑：

使用php artisan make:seeder UserSeeder 创建一个新的播种器

编辑播种器以“播种”必要的数据。例如：

DB::table('users')->insert([
    'name' => 'John Doe',
    'email' => 'johndoe@example.com',
    'password' => Hash::make('password'),
]);

然后调用内置的 artisan 函数 php artisan migrate:fresh --seed，它将删除所有表并重新运行所有迁移，然后使用播种机播种数据。

您可以阅读有关此过程的更多信息here。

原文：

如果您打算从长远来看支持实时应用程序，那么您很可能会有很多这些单独的迁移文件，每次创建新的迁移文件时仍然会伤害您的强迫症。每次我创建一个新的迁移来更改表时都会发生这种情况，哈哈。

但是，在开发过程中，如果您正在使用私有代码库并且没有其他开发人员会尝试跟上您的更改，我可以理解您的观点。如果这样做，您对旧迁移文件所做的任何更改都将很难让他们模仿，因为迁移表会跟踪需要运行的迁移（如果有的话），所以如果其他人在您尝试迁移之后改变了之前的迁移，什么都不会发生。

我会做的是在 Laravel 中设置一个数据库播种器，以便在回滚迁移时快速重新为表中的数据重新播种，或者获取表的 sql 转储并在再次迁移后重新插入它.

您可以考虑的另一件事是，在开发的这个阶段不要担心迁移目录，一旦您准备好部署或推送，请检查您的表更改并将它们“重构”到您想要的迁移中。但一定要在此之后进行一些彻底的测试，以确保您不会遗漏任何列或更改。