多用户类型下共享多对多团队字段的方案优化咨询

问题背景 #

咱们的系统里有三类用户：企业（Company）、司机（Driver）、客户（Client），其中企业和司机需要团队功能——可以邀请司机加入团队，二者都得有team多对多字段。现在有两种实现方案，想问问有没有更好的做法，或者选哪种更合适。

现有方案复盘 #

方案一：把team字段直接放在BaseUser里 #

• 优点：实现简单，不用搞复杂的模型继承或关联，开发速度快
• 缺点：客户（Client）完全用不上团队功能，但数据库里每条Client记录都会多一个team字段，纯粹浪费存储空间

方案二：做个带team字段的抽象模型，让Company和Driver继承它 #

• 优点：Client的数据库记录里不会有多余的team字段，数据存储更干净
• 缺点：
  • 代码量增加，模型结构相对复杂
  • 处理邀请和加入逻辑时，得先判断发起者是企业还是司机，逻辑复杂度提升
  • 邀请对象需额外关联CompanyMembership和DriverMembership字段，过期邀请还要用Celery定时清理，新增不少额外工作

更优方案：独立团队模型+关联中间表 #

我推荐采用这种方案，逻辑清晰且无冗余，具体思路如下：

核心逻辑 #

1. 单独创建Team模型，存储团队基础信息（如名称、创建时间、创建人等）
2. 为企业、司机分别建立与Team的关联表（或直接用多对多字段），客户完全不与Team挂钩
3. 单独做一个TeamInvitation模型，统一处理邀请逻辑，无需区分发起者类型

代码示例（关键部分） #

from django.db import models
from django.contrib.auth.models import AbstractBaseUser, BaseUserManager

# 自定义用户管理器（基础实现省略）
class CustomUserManager(BaseUserManager):
    pass

# 基础用户模型
class BaseUser(AbstractBaseUser):
    USER_TYPE_CHOICES = (
        ('company', '企业'),
        ('driver', '司机'),
        ('client', '客户'),
    )
    user_type = models.CharField(max_length=20, choices=USER_TYPE_CHOICES)
    # 其他基础字段（如手机号、邮箱等）自行补充

# 独立团队模型
class Team(models.Model):
    name = models.CharField(max_length=100, verbose_name='团队名称')
    created_at = models.DateTimeField(auto_now_add=True, verbose_name='创建时间')
    # 创建人关联基础用户，限制仅企业或司机可创建
    creator = models.ForeignKey(
        BaseUser, 
        on_delete=models.CASCADE, 
        related_name='created_teams',
        limit_choices_to={'user_type__in': ['company', 'driver']},
        verbose_name='创建人'
    )

# 企业与团队的关联表
class CompanyTeam(models.Model):
    company = models.ForeignKey(
        BaseUser, 
        on_delete=models.CASCADE, 
        limit_choices_to={'user_type': 'company'},
        verbose_name='关联企业'
    )
    team = models.ForeignKey(Team, on_delete=models.CASCADE, verbose_name='关联团队')
    joined_at = models.DateTimeField(auto_now_add=True, verbose_name='加入时间')

# 司机与团队的关联表
class DriverTeam(models.Model):
    driver = models.ForeignKey(
        BaseUser, 
        on_delete=models.CASCADE, 
        limit_choices_to={'user_type': 'driver'},
        verbose_name='关联司机'
    )
    team = models.ForeignKey(Team, on_delete=models.CASCADE, verbose_name='关联团队')
    joined_at = models.DateTimeField(auto_now_add=True, verbose_name='加入时间')

# 统一邀请模型
class TeamInvitation(models.Model):
    INVITATION_STATUS = (
        ('pending', '待处理'),
        ('accepted', '已接受'),
        ('rejected', '已拒绝'),
        ('expired', '已过期'),
    )
    team = models.ForeignKey(Team, on_delete=models.CASCADE, verbose_name='邀请加入的团队')
    inviter = models.ForeignKey(
        BaseUser, 
        on_delete=models.CASCADE, 
        limit_choices_to={'user_type__in': ['company', 'driver']},
        verbose_name='邀请人'
    )
    invitee = models.ForeignKey(
        BaseUser, 
        on_delete=models.CASCADE, 
        limit_choices_to={'user_type': 'driver'},
        verbose_name='被邀请司机'
    )
    status = models.CharField(max_length=20, choices=INVITATION_STATUS, default='pending', verbose_name='邀请状态')
    created_at = models.DateTimeField(auto_now_add=True, verbose_name='创建时间')
    expired_at = models.DateTimeField(verbose_name='过期时间')

该方案优势 #

• 无冗余字段：Client用户完全不涉及团队相关数据，数据库存储干净
• 逻辑清晰：团队信息独立存储，关联关系一目了然，邀请逻辑统一处理，无需区分发起者类型
• 扩展性强：后续给团队加权限、公告等功能，直接扩展Team模型即可，不用修改用户模型
• 过期邀请处理简单：用Celery写定时任务，扫描TeamInvitation中过期记录并统一更新状态，逻辑单一易维护

方案选择建议 #

• 如果系统规模小、团队功能需求简单，方案一足够用——冗余字段的开销在数据量不大时可忽略，省得折腾
• 如果系统有长期迭代计划、对数据合理性要求高，独立团队模型方案是最优选择，后续维护成本低
• 如果不想新增太多模型，方案二也可接受，但建议把邀请逻辑封装成通用方法（比如写个send_team_invite函数），避免重复代码，降低维护复杂度

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