Django 全局禁用外键

Django ORM 是我最喜欢的 ORM，它自带了全套数据库管理的解决方案，开箱即用。但是到了某一家公司里就有些水土不服。比如分享了如何在你家公司使用 Django Migrate。这次我们来说说外键。

什么是外键

关系型数据库之所以叫「关系型」，因为维护数据之间的「关系」是它们的一大 Feature。

外键就是维护关系的基石。

比如我们创建两个表，一个是 students 学生表，一个是 enrollments 选课表。

MySQL root@(none):foreignkey_example1> select * from students;
+----+------+
| id | name |
+----+------+
| 1  | 张三 |
| 2  | 李四 |
+----+------+
2 rows in set
Time: 0.002s

MySQL root@(none):foreignkey_example1> select * from enrollments;
+----+------------+--------+
| id | student_id | course |
+----+------------+--------+
| 1  | 1          | 数学   |
| 2  | 2          | 语文   |
| 4  | 1          | 英语   |
+----+------------+--------+
3 rows in set
Time: 0.002s

选课表的 student_id 和 student.id 关联。那么外键在这里为我们做了什么呢？

enrollments 创建的 SQL 如下：

CREATE TABLE `enrollments` (
  `id` int NOT NULL AUTO_INCREMENT,
  `student_id` int NOT NULL,
  `course` varchar(50) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `student_id` (`student_id`),
  CONSTRAINT `enrollments_ibfk_1` FOREIGN KEY (`student_id`) REFERENCES `students` (`id`)
)

其中 CONSTRAINT enrollments_ibfk_1 FOREIGN KEY (student_id) REFERENCES 就是外键的意思。这样确保 enrollments 表中的 student_id 必须来自 students 表中的 id。enrollments.student_id 里的值，必须是 students.id 表中已经存在的值。
否则数据库会报错，防止插入无效的数据。

如果我们试图插入一条不存在的 student_id，数据库会拒绝插入：

MySQL root@(none):foreignkey_example1> INSERT INTO enrollments (student_id, course) VALUES (3, '英语');
                                    ->
(1452, 'Cannot add or update a child row: a foreign key constraint fails (`foreignkey_example1`.`enrollments`, CONSTRAINT `enrollments_ibfk_1` FOREIGN KEY (`student_id`) REFERENCES `students` (`id`))')

使用外键的好处有：

数据库帮我们维护数据的完整性，不会存在孤儿数据，不会因为编程错误插入错误数据；
可以实现级联删除，比如 ON DELETE CASCADE，上面的例子中当我们从 students 表删除 id=2 的学生，在 enrollments 表相关的数据也同事会被删除；
清晰的业务逻辑表达，在数据库表定义就有二者的关联关系，在语义上就比较好维护。还有一些数据库工具可以直接根据我们表定义中的 FOREIGN KEY 关系来画出来表之间的关系，在入手一个新的项目的时候，非常有用。

为什么 DBA 不喜欢外键？

很多大公司的数据库都是禁用外键的，FOREIGN KEY (student_id) REFERENCES 这种 DDL 语句执行会直接失败。这样，数据库的表从结构上看不再有关系，每一个表都是独立的表而已，enrollments 表的 student_id Column 只是一个 INT 值，不再和其他的表关联。

为什么要把这个好东西禁用呢？

主要原因是不好维护。修改表结构和运维的时候，因为外键的存在，都会有很多限制。分库分表也不好实现。如果每一个表都是一个单独的表，没有关系，那 DBA 运维起来就方便很多了。

外键也会稍微降低性能。因为每次更新数据的时候，数据库都要去检查外键约束。

退一步讲，其实数据的完整性可以通过业务来保证，级联删除这些东西也做到业务的逻辑代码中。这样看来，使用外键就像是把一部分业务逻辑交给数据库去做了，本质上和存储过程差不多。

所以，互联网公司的数据库一般都是没有 REFERENCES 权限的。

Revoke REFERENCE 权限如下这样操作：

REVOKE REFERENCES ON testdb1_nofk.* FROM 'testuser1'@'localhost';

这样之后，如果在执行 Django migration 的时候，会遇到权限错误：

django.db.utils.OperationalError: (1142, "REFERENCES command denied to user 'testuser1'@'localhost' for table 'testdb1_nofk.django_content_type'")

Django migration 如何不使用外键

在声明 Model 的时候，使用 ForeignKey 要设置 db_constraint=False²。这样在生成的 migration 就不会带外键约束了。

Django migration 如何全局禁用外键

每一个 ForeignKey 都要写这个参数，太繁琐了。况且，Django 会内置一些 table 存储用户和 migration 等信息，对这些内置 table 修改 DDL 比较困难。

Django 的内置 tables：

+-------------------------------+
| Tables_in_test_nofk           |
+-------------------------------+
| auth_group                    |
| auth_group_permissions        |
| auth_permission               |
| auth_user                     |
| auth_user_groups              |
| auth_user_user_permissions    |
| django_admin_log              |
| django_content_type           |
| django_migrations             |
| django_session                |
+-------------------------------+

在 Github 看到一个项目³，发现 Django 的 ORM 里面是有 feature set 声明的，其实，我们只要修改 ORM 的 MySQL 引擎，声明数据库不支持外键，ORM 在生成 DDL 的时候，就不会带有 FOREIGN KEY REFERENCE 了。

核心的原理是继承 Django 的 MySQL 引擎，写自己的引擎，改动内容其实就是一行 supports_foreign_keys = False。

具体的方法如下。

新建一个 mysql_engine，位置在 Django 项目的目录下，和其他的 app 平级。这样 mysql_engine 就可以在 Django 项目中 import 了。

├── project_dir
│   ├── __init__.py
│   ├── __pycache__
│   ├── asgi.py
│   ├── settings
│   ├── urls.py
│   └── wsgi.py
├── manage.py
├── app_dir
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── migrations
│   ├── models.py
│   ├── serializers.py
│   ├── tests.py
│   └── views.py
└── mysql_engine
    ├── base.py
    └── features.py

我们要写自己的 mysql engine。为什么不直接使用 django_psdb_engine 项目呢？因为 django_psdb_engine 是继承自 Django 原生的 engine，就无法使用 django_prometheus⁴ 的功能了。ORM 扩展的方式是继承，这就导致如果两个功能都是继承自同一个基类，那么只能在两个功能之间二选一了，或者自己直接基于其中一个功能去实现另一个功能。所以不如链式调用好，如 CoreDNS⁵ 的 plugin，可以包装无限层，接口统一，任意插件可以在之间插拔。Django 自己的 middleware 机制也是这样。

engine 里面主要写两个文件。

base.py

from django_prometheus.db.backends.mysql.base import DatabaseWrapper as MysqlDatabaseWrapper
from .features import DatabaseFeatures


class DatabaseWrapper(MysqlDatabaseWrapper):
    vendor = 'laixintao'
    features_class = DatabaseFeatures

features.py

from django_prometheus.db.backends.mysql.base import (
    DatabaseFeatures as MysqlBaseDatabaseFeatures,
)


class DatabaseFeatures(MysqlBaseDatabaseFeatures):
    supports_foreign_keys = False

最后，在 settings.py 中，直接把 ENGINE 改成自己的这个包 "ENGINE": "mysql_engine"。

DATABASES = {
    "default": {
        "ENGINE": "mysql_engine",
        "NAME": "testdb1_nofk",
        "USER": "testuser1",
        'HOST': 'localhost',
        'PORT': '',
        'OPTIONS': {
            'unix_socket': '/tmp/mysql.sock',
        },
    }
}

这样之后就完成了。

python manage.py makemgirations 命令不受影响。

python manage.py migrate 命令现在不会对 ForeignKey 生成 REFERENCE 了。

Django 的 migrate 可以正常执行，即使 Django 内置的 table 也不会带有 REFERENCE。

python3 corelink/manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, meta, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying auth.0012_alter_user_first_name_max_length... OK

查看一个 table 的创建命令：

MySQL root@(none):testdb1_nofk> show create table auth_user_groups \G
***************************[ 1. row ]***************************
Table        | auth_user_groups
Create Table | CREATE TABLE `auth_user_groups` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `user_id` int NOT NULL,
  `group_id` int NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `auth_user_groups_user_id_group_id_94350c0c_uniq` (`user_id`,`group_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

可以确认是没有 REFERENCE 的。

chartdb 工具：https://app.chartdb.io/，其他类似的工具还有很多，比如 https://dbdiagram.io/ ↩︎
db_constraint=False 文档：https://docs.djangoproject.com/en/5.2/ref/models/fields/#django.db.models.ForeignKey.db_constraint ↩︎
https://github.com/planetscale/django_psdb_engine ↩︎
https://github.com/korfuri/django-prometheus ↩︎
https://www.kawabangga.com/posts/4728 ↩︎

推荐订阅源

卡瓦邦噶！

什么是外键

为什么 DBA 不喜欢外键？

Django migration 如何不使用外键

Django migration 如何全局禁用外键