Django如何在模型/数据库层面禁止创建邮箱已存在的Invitation对象

可行实现方案 #

你提到的需求完全可以实现，目前有两类主流实现方式，分别对应Django模型层和数据库层，具体如下：

方案1：Django模型层校验（重写clean + save方法） #

这个方案是Django原生支持的模型层面校验，不需要修改数据库结构，实现成本最低：

实现代码

from django.core.exceptions import ValidationError
from django.contrib.auth import get_user_model
from django.db import models

User = get_user_model()

class Invitation(models.Model):
    email = models.EmailField(unique=True)
    # 其余字段按需添加

    def clean(self):
        # 模型层面统一校验逻辑
        super().clean()
        if User.objects.filter(email=self.email).exists():
            raise ValidationError({"email": f"邮箱 {self.email} 已存在于用户表，无法创建邀请"})

    def save(self, *args, **kwargs):
        # 保存前自动触发校验，无需上层手动调用full_clean
        self.full_clean()
        super().save(*args, **kwargs)

优缺点

• 优点：纯Django原生逻辑，和数据库无关，代码好维护，校验逻辑可以灵活扩展
• 缺点：仅通过Django ORM操作时生效，如果有人直接用原生SQL、第三方工具操作数据库，校验会失效，存在极少量绕过风险

方案2：数据库触发器（完全数据库层面校验） #

如果要求绝对的校验可靠性，不允许任何绕过的可能，可以用数据库触发器实现跨表校验，这个逻辑直接运行在数据库层，任何上层操作都无法跳过：

实现步骤

以PostgreSQL为例：

1. 生成空迁移文件：

python manage.py makemigrations --empty your_app_name

2. 在生成的空迁移文件中添加触发器SQL：

from django.db import migrations

class Migration(migrations.Migration):
    dependencies = [
        ("your_app_name", "000x_previous_migration"),
    ]

    operations = [
        migrations.RunSQL(
            # 向前执行的SQL：创建校验函数 + 触发器
            """
            CREATE OR REPLACE FUNCTION check_invitation_email_exists()
            RETURNS TRIGGER AS $$
            BEGIN
                IF EXISTS (SELECT 1 FROM auth_user WHERE email = NEW.email) THEN
                    RAISE EXCEPTION '邮箱 % 已存在于用户表，无法创建邀请', NEW.email;
                END IF;
                RETURN NEW;
            END;
            $$ LANGUAGE plpgsql;

            CREATE TRIGGER trigger_check_invitation_email
            BEFORE INSERT OR UPDATE OF email ON invitation
            FOR EACH ROW EXECUTE FUNCTION check_invitation_email_exists();
            """,
            # 回滚的SQL：删除触发器 + 函数
            """
            DROP TRIGGER IF EXISTS trigger_check_invitation_email ON invitation;
            DROP FUNCTION IF EXISTS check_invitation_email_exists();
            """
        )
    ]

3. 执行迁移生效：

python manage.py migrate

优缺点

• 优点：完全在数据库层面生效，无论上层用什么方式操作数据库，校验都不会被绕过，可靠性最高
• 缺点：和数据库类型绑定，如果更换数据库（比如从PostgreSQL换成MySQL）需要重写触发器逻辑，维护成本略高

补充说明 #

你之前考虑的UniqueConstraint无法实现该需求，因为无论是Django的UniqueConstraint还是原生数据库的唯一约束，都只能作用于单张表的字段，无法直接关联另一张表做跨表校验。

内容的提问来源于stack exchange，提问作者Milano