1.前言

当我们在 Django 中添加或更改数据库模型时，一般需要进行 makemigration 并设置模型类来创建表对应的数据库，或者更改对应的表结构。非常方便。

但是在实际使用中执行这两个命令时，经常会出现意想不到的错误。下面将为您详细讲解这两个命令，以便您更加放心地使用！ ？执行命令python manage.py makemigrations会创建一个迁移文件（如果没有创建迁移文件，记得添加文件[apps.py]并编辑，上传到INSTALLED_APPS就是名字） 如果我们有多个应用程序文件，可以指定应用程序的名称来生成迁移文件。命令 python manage.py makemigration [app_label]

一般来说，使用这个命令就足够了！

当然，我们还会使用其他命令，例如执行python manage.py makemigrations --dry-run --verbosity 3。创建迁移文件的代码

可以使用 python管理。 py makemigrations --no-header 创建一个没有 django 版本和迁移时间规范的迁移文件

可以选择添加配置元素 managed=False amin '当时对应的模型代码忽略再次执行makemigrations，模型的迁移代码将不会发布！

还有其他命令，但不常用。您可以阅读官方文档了解更多

2。协同开发时，如何解决迁移文件冲突？

在使用git进行协作开发时，我们应该有一个规则，团队中的每个人都不能修改同一个模型文件。但不保证所有提交都能避免移民纠纷！

目前我们可以使用python manage.py makemigrations --merge进行合并来自动调整冲突，但这仅适用于简单的模型合并。如果这样太复杂，建议阅读Django的[writing-migration]部分来修改迁移文件

3。 migrate

将移民文件与数据库进行匹配。

如果要部署应用程序进行迁移，可以使用python3 manage.py migrate[app_label]

如果要部署迁移文件，可以使用3.python3migrate[ app_label] [name_migration] 示例：python manage.py Case migrate 0011_auto_20220726_1440

使用♽♽♽♽创建项目后，如果需要使用django的用户管理、数据库迁移及其他功能，我们还需要配置数据库连接，然后分别执行。被记录。

有一个问题是我们的项目没有移民档案，那么migrate从哪里得到移民的移民档案呢？

我们可以在 [C:\Users\Computer Username\AppData\Local\Programs\Python\Python39\Lib\site-packages\django\contrib\auth\migrations ] 中找到用户模型迁移文件。

还可以添加参数--DATABASE-DATABASE来指定发送的数据库

也可以使用--破坏发送计划❀

4.迁移 如果我报告了错误，我该怎么办？

有时候，当我们直接更改数据库表字段而不更改对应的模型代码，然后执行makemigration时，migrate会报错！

类似以下操作：

1）直接从数据库表中删除关键字段

2）然后删除对应型号代码中的【key】字段

3）此时重新放入makemigrations 和 migrate，您会看到 migrate 在 时报告了错误，这是我们从 'the 中删除 的原因主键数据该字段，进入修改后的模型文件创建并传输迁移文件。当migrate时，会执行删除key，但是我们的表已经不再包含这个字段了，所以会报错！

遇到这种情况，我们可以使用migrate --fake来修复。

如果应用，它将标记到目标的迁移操作，但不会实际运行 SQL 来更改数据库结构。

此外，如果 CreateModel 执行迁移操作时数据库表已存在，则使用 migrate --fake-initial 允许 Django 跳过应用程序的初始迁移。当首次使用迁移对现有数据库执行迁移时，此选项非常有用。但是，此选项不会根据相应的表名称检查数据库架构，因此如果您确定现有架构与迁移中包含的架构匹配，则可以安全地使用。-first resident！

还有其他不常用的命令动作。如果需要了解更多可以查看官方文档

3。是否需要导入外键约束？

如果有外键，使用migrate 外键约束将被安装到数据库中。这是一个非常好的功能。当老师在学校教书时，我们也被要求设定重要的外部约束。

但这在实际应用中并不是一个好的选择，《阿里Java开发规范手册》中明确指出：【强制】不允许外键和级联，外键概念都必须在实践中解决。 Layer

为什么要做这样的程序？我们可以举个例子来说明：

我们现在已经创建了两个模型：[产品和项目]，[项目]的字段产品，关系产品♽

我们迁移并修改数据库表

可以看到[project]表有外键约束记录

将文件project_id添加到[ project]表时，会报错因为表没有对应的记录而报错【结果】：

事实证明，这个约束的存在会保证表之间关系的完整性。脏数据不太明显。这就是外键约束的一个明显优势！

但也有不可忽视的缺陷：

性能问题

我们刚刚创建了两个表【项目】和【产品】。 [project] 表使用字段 project_id，[Product] 表具有外键约束。

目前，每当我们往【project】表中插入数据时，都会先去【results】询问是否有相关数据。如果以编程方式控制，则不需要提出此请求。但如果设置了外键约束，则保证满足请求。这实在是不够。当相关字段较少时，可能没有效果，但是当相关字段过多时，效果尤其明显！

死锁

每次更改【项目】数据时，我们都需要检查【结果】表中的数据，并获得额外的锁。在高度拥堵、高流量的环境下，较大的外部约束可能会导致停电！

开发/测试效率下降

在日常测试过程中，我们经常会遇到这样的情况：我们有BUG，想要发布它或者让测试变得更容易。我们会直接修改数据库表中的数据来达到正确的测试结果。 。

虽然它不是标准的，但现实是它可以提高我们的表现。这个毋庸置疑！但这样的行为也会带来问题，比如数据引起的bug，但并不是程序的bug，或者潜在的bug没有被发现。

所以我的建议是这样的：如果你的业务比较复杂，可以在测试环境中使用外键约束，但是在生产环境中需要去掉！如果你的业务很简单，你可以完全删除外键约束！

在Django中，即使你从数据库中删除了外键约束，只要你的模型代码中存在外键关系，你仍然可以使用ORM来执行你的外键操作。没有区别！ ？

指定型号inspectdb产品作者：瞿鸟
链接：https://juejin.c02/49/97/post来源：稀土矿块
嗬作者保留所有权利。如需商业印刷，请联系作者以获得许可。非商业转载请注明来源。