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

Question

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

我了解迁移的一般过程及其服务的目的，并且很高兴以预期的方式使用它们，即在整个应用程序生命周期中添加和删除必要的字段。

我的疑问是，在项目的最初阶段，我很少知道给定 table 中我需要的许多字段，而在项目的早期阶段，我想获得主要内容功能和关系设置，也许只是在客户做出决定之前使用一些无用的字段。

最重要的是，知道那里有额外的迁移文件可能看起来与项目的 v1.0 完全不同，这伤害了我的强迫症...一旦我达到 v0.5，我可能会决定我已经走得够远了，可以开始了正确管理迁移。

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

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

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

这样做会不会出错:

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

感觉好像有副作用，回滚可能搞砸了，是这样吗？迁移 table 起什么作用，因为这似乎在实践中有效？

最后的话

请记住，这只是我试图理解的一个概念。如果是绝对不好的做法无论在什么情况下我都可以接受！

Answer 1

编辑：

使用 php artisan make:seeder UserSeeder

创建一个新的播种机

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

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

然后调用 built-in artisan 函数 php artisan migrate:fresh --seed，这将删除所有 table 和 re-run 所有迁移，然后使用播种器播种数据。

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

原文：

如果您计划在长期运行中支持实时应用程序，您很可能会有很多这样的单独迁移文件，每次创建新文件时它们仍然会伤害您的 OCD。每次我创建一个新的迁移来改变 table 时，它都会发生在我身上，哈哈。

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

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

您可以考虑的另一件事是，在开发的这个阶段不要担心迁移目录，一旦您准备好部署或推送，请进行 table 更改和某种“重构”他们进入你想要的迁移。但绝对运行在此之后进行一些彻底的测试，以确保您没有遗漏任何列或更改。

Is there an alternative migrations workflow for very early stages of development. Laravel