在应用之间迁移模型。
简短的答案是， 不要这样做！！
但是，这种答案在现实生活中的项目和生产数据库的现实世界中很少起作用。因此，我创建了一个示例GitHub存储库来演示这个相当复杂的过程。
我正在使用MySQL。 （不，这些不是我的真实凭证）。
问题
我使用的示例是带有 汽车 应用程序的工厂项目，该应用程序最初具有
Car模型和
Tires模型。
factory |_ cars |_ Car |_ Tires
该
Car模型具有与的ForeignKey关系
Tires。（同样，您可以通过汽车模型指定轮胎）。
但是，我们很快意识到这
Tires将是一个具有自己的视图等的大型模型，因此我们希望在其自己的应用程序中使用它。因此，所需的结构为：
factory |_ cars |_ Car |_ tires |_ Tires
而且我们需要保持
Car和之间的ForeignKey关系，
Tires因为太多依赖于保留数据。
解决方案
步骤1. 设置具有不良设计的初始应用程序。
浏览步骤1的代码。
步骤2. 创建一个管理界面，并添加一堆包含ForeignKey关系的数据。
查看步骤2。
步骤3.
决定将
Tires模型移至其自己的应用程序。认真地将代码粘贴到新的轮胎应用中。确保更新
Car模型以指向新
tires.Tires模型。
然后运行
./manage.py makemigrations数据库并将其备份到某个地方（以防万一这失败了）。
最后，运行
./manage.py migrate并查看Doom的错误消息，
django.db.utils.IntegrityError：（1217，’无法删除或更新父行：外键约束失败’）
到目前为止，在步骤3中查看代码和迁移。
步骤4. 棘手的部分。自动生成的迁移无法看到您只是将模型复制到其他应用程序。因此，我们必须做一些事情来纠正这一问题。
您可以按照步骤4的说明进行操作，并查看最终的迁移。我确实对此进行了测试以验证其是否有效。
首先，我们将继续工作
cars。您必须进行新的空迁移。实际上，此迁移需要在最近创建的迁移（执行失败的迁移）之前运行。因此，我对创建的迁移进行了重新编号，并更改了相关性，以首先运行该自定义迁移，然后运行该
cars应用程序的最后一个自动生成的迁移。
您可以使用以下方法创建一个空迁移：
./manage.py makemigrations --empty cars
步骤4.a. 进行自定义 old_app 迁移。
在第一个自定义迁移中，我将仅执行“
database_operations”迁移。Django为您提供了拆分“状态”和“数据库”操作的选项。您可以通过在此处查看代码来了解如何完成此操作。
我第一步的目标是将数据库表从重命名
oldapp_model为
newapp_model而不弄乱Django的状态。您必须确定Django将根据应用程序名称和模型名称为数据库表命名的方式。
现在，您可以修改初始
tires迁移了。
步骤4.b. 修改 new_app 初始迁移
操作很好，但是我们只想修改“状态”，而不是数据库。为什么？因为我们要保留
cars应用程序中的数据库表。另外，您需要确保先前进行的自定义迁移是该迁移的依赖项。请参阅轮胎迁移文件。
因此，现在我们已在数据库中重命名
cars.Tires为
tires.Tires，并更改了Django状态以识别该
tires.Tires表。
步骤4.c. 修改 old_app 最后一次自动生成的迁移。
去 背 到汽车，我们需要修改最后自动生成的迁移。它应该需要我们的第一个定制汽车迁移和最初的轮胎迁移（我们刚刚修改）。
这里我们应该离开
AlterField操作，因为
Car模型 指向
的是另一个模型（即使它具有相同的数据）。但是，
DeleteModel由于
cars.Tires模型已不存在，因此我们需要删除与之相关的迁移线。已完全转换为
tires.Tires。查看此迁移。
步骤4.d. 清理 old_app中的 陈旧模型。
最后但并非最不重要的一点是，您需要在cars应用中进行最终的自定义迁移。在这里，我们将执行“状态”操作，仅删除
cars.Tires模型。它是仅状态的，因为的数据库表
cars.Tires已被重命名。这最后的迁移清理剩余的Django的状态。
