我有我的迁移文件，它为数据库创建初始架构，我有我的种子文件，它用随机数据和集合类型填充初始架构。
我对迁移和种子的理解是，每当有新团队成员加入时，他都可以运行它们并快速处理所有数据库更改和产品工作所需的数据，此外，您可以通过运行迁移文件将更改应用于 stg 和 prod。
但是，随着我项目的进展，新类型的数据不断涌现，应用它们的唯一方法是创建一个迁移，将插入运行到数据库中。
我遇到的问题是，工匠处理迁移和种子的方式是，它首先运行所有迁移，然后运行所有种子，我似乎没有办法指定它们应该运行的顺序。因此，如果我运行 migrate：refresh --seed，我会遇到错误，因为它应用了最新的迁移，在种子插入自己的数据之前插入新数据（可能会也可能不会，取决于种子中插入的类型）。
我们尝试的一种解决方案是更新种子，并在应用插入数据的迁移更改之前进行检查，但这维护起来变得非常麻烦。
此方案的迁移和种子的预期用途是什么？
更新为了更清楚地说明：假设我有一个迁移来创建用户：用户：{id， 名称， 类型}我有我的种子来创建用户。
我同时运行两者，并且我有一个包含大量用户的用户表。
时间流逝，我们决定我们需要一张user_types表。将创建一个迁移，该迁移将创建新表，并填充新用户类型的数据和更新以将当前 user.type 与user.type_id匹配。
开发人员运行迁移，他们拥有最新的数据库。
新的开发人员加入团队。他负责迁移。然后是种子。它坏了。
现在，如果我们更新种子以匹配最新种子，我们将遇到user_types表的重复数据。为了避免这种情况，我们需要在迁移中使用某种防御性代码，以便在没有数据时不运行内容，如果有数据则进行更新。
问题是，这是使用迁移的正确方法吗？如何将数据更改推送给所有开发人员，而无需重新运行种子？
我认为迁移不应该依赖于种子中的任何数据。种子应该期待最新的迁移架构。因此，每当架构更改时，都应相应地更新种子并执行迁移：fresh --seed。至少，这就是我正在做的事情。
由于您已经在这样做，我想知道是什么使它对您来说是一个"麻烦的过程"。你能详细说明一下吗？
从你的解释中，我想我明白了。
播种机应该做的第一件事是删除所有内容，以便始终从空数据库开始，至少在播种机应该关注的地方。
我还会仔细查看文档 https://laravel.com/docs/5.2/seeding 特别是"使用模型工厂"部分。
public function run()
{
factory(AppUser::class, 50)->create()->each(function($u) {
$u->posts()->save(factory(AppPost::class)->make());
});
}
在这种情况下，你会做类似的事情，除了你从顶部开始，这对你来说是user_types，然后对于它创建的每种类型，它会生成你需要的多少用户。 这似乎与您当前的流程略有不同，在当前流程中，听起来每个表都有一个播种机文件。
这样，您就可以在代码中处理并非常清楚地处理父/子关系，并且将来添加其他项非常容易。 此外，由于每次播种机运行时您基本上都是从头开始，因此您可以确定这将适用于新的和现有的开发人员。