Laravel开发类Uber应用的司机与用户数据库结构设计选型

直接给结论：选分表方案，别用单表方案，下面把两种方案的问题、落地细节说清楚： #

单表方案的问题与身份校验逻辑 #

单表方案看似开发快，实际后续维护成本极高：

• 只要后续迭代加字段，不管是乘客专属的常用地址、信用分，还是司机专属的从业资格证、接单偏好、车辆绑定信息，都会往users表堆，最后整张表一半字段是空值，结构混乱。
• 针对你提到的「怎么确保行程关联的是真司机不是普通用户」的问题，单表方案没有数据库层面的兜底方案，只能靠业务代码硬卡：
  • 行程表的driver_id关联users.id，所有涉及司机的查询都必须带上type = 'driver'的过滤条件
  • Laravel模型里给关联加固定条件：

    // Trip模型里的司机关联
    public function driver()
    {
        return $this->belongsTo(User::class)->where('type', 'driver');
    }
    

  • 这套逻辑只要哪个开发漏写判断，就会出现普通用户被当成司机关联到行程的脏数据，外键约束根本没法加，风险完全不可控。

分表方案落地细节（推荐） #

先直接答你最关心的两个问题：

1. drivers表主键怎么选 #

直接复用users表主键，不要搞独立自增id+user_id的冗余结构。
司机身份和基础用户是严格1:1关系，一个用户最多对应一个司机账号，把drivers表的主键id同时作为关联users表的外键即可，不需要额外存user_id字段。
如果非要用独立自增id，你还得给user_id加唯一索引防止一个用户绑多个司机资料，本质和直接用id当外键效果一样，平白多了个无意义的自增字段，完全没必要。
调整后的drivers表字段非常干净：id（主键+外键关联users.id）、license_number（驾照编号）、years_driving（驾龄）、rating（服务评分）、bio（个人简介），后续加司机专属字段直接往这张表堆就行。

2. 1:1关联关系怎么配 #

外键存在drivers表，两边模型都可以写关联，Laravel里的写法如下：

• 基础User模型中，关联对应的司机资料：

  public function driver()
  {
      return $this->hasOne(Driver::class, 'id');
  }
  

• Driver模型中，关联对应的基础用户信息：

  public function user()
  {
      return $this->belongsTo(User::class, 'id');
  }
  

分表方案的核心优势 #

• 数据库层面直接做外键约束：行程表设两个关联字段，passenger_id关联users.id（所有注册用户都可以当乘客），driver_id关联drivers.id，从根上杜绝把普通用户关联成司机的脏数据问题，不需要靠业务代码反复判断。
• 扩展成本极低：司机端的车辆绑定、接单记录、提现账户、违规记录全部关联drivers表；乘客端的行程记录、常用地址、支付方式全部关联users表，职责完全不耦合。
• 和Laravel默认认证体系100%兼容：登录、鉴权全走默认的users表即可，判断用户有没有司机权限，只需要查$user->driver是否存在就行，不需要改核心认证逻辑。

补充落地提醒 #

• 别把司机、乘客拆成两个独立的认证 guard，后续token管理、权限判断会多出大量重复代码，完全没必要。
• 用户申请成为司机的流程也非常好处理：等用户提交驾照等资料审核通过后，直接在drivers表插入一条id等于当前用户id的记录即可，不需要改动users表原有数据。
• 司机评分、驾龄这类只有司机才有的字段，全部放在drivers表，别往users表塞。

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