在开发的早期阶段是否有替代的迁移工作流程 Laravel

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

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

我的查询是，在项目的一开始，我很少了解给定表中需要的许多字段，而在项目的早期，我想设置主要功能和关系，也许在客户下定决心之前只使用一些简短的字段即可。

最重要的是，我知道那里有额外的迁移文件，它们看起来可能像项目的v1.0一样，这让我的OCD感到痛苦...一旦达到v0.5，我可能会决定立即进行适当的管理迁移。

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

在项目的早期阶段一次又一次地重复使用相同的迁移脚本，而不必担心数据丢失或回滚的最干净的步骤是什么。

只需添加一下，我就不想刷新整个迁移，因为我真的很想保留我正在玩的任何数据，尤其是保留用于登录后端等的用户表。

这样做会错吗？

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

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

最后一句话

请记住，这只是我想引起注意的一个概念。如果在任何情况下都是绝对不好的做法，我都可以接受！

编辑：

使用php artisan make:seeder UserSeeder

创建一个新的播种机

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

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

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

您可以了解有关此过程here的更多信息。

原始：

如果您打算长期支持一个实时应用程序，则很可能会有很多这些单独的迁移文件，而这些文件每次制作新文件时仍然会损害OCD。每当我创建一个新的迁移来更改表时都会发生这种情况，哈哈。

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

我要做的是在Laravel中设置数据库播种器，以便在回滚迁移时可以快速重新放置表中的数据，或者获取表的sql dump并在再次迁移后重新插入

您可能要考虑的另一件事是，不必担心开发阶段的迁移目录，一旦准备好部署或推送，请对表进行更改，然后将其“重构”为所需的迁移。但是一定要在此之后进行一些彻底的测试，以确保您不会遗漏任何列或更改。