可扩展的用户表设计

最近我也刚刚做了类似的事情，不过我的做法和你有点不一样，针对不同的登录终端我都会有一个对应的用户表例如 wechat_official_accounts, wechat_mini_program_accounts, h5_mobile_accounts，同时我也设计了一个登录无关的用户表叫biz_users，里面使用了morphTo()来关联不同的实际登录表，同样的针对不同的登录来源有不同的登录controller负责，一旦登录完成在session中存储的都是BizUser实体，这样在后续的业务操作中我不需要考虑登录来源所有的业务操作都围绕BizUser，就算以后要添加登录方式，也非常简单了。

@Handle 原理上其实差不都，我是使用oauths表来对应你的多个用户表的，不过你那样写的话确实职责更明确，我的想法是直接一个登陆注册逻辑然后都遵循一个规则，你的是各论各的，互不影响，很赞

换个方式

小项目的话，用户的主信息字段是固定的，不固定增减多也影响不大。
大项目的话，用户的主信息字段是固定的，不怎么增减，如果增减频繁，换个产品经理就是了。

oauth 这一块，目前也就这么几家，短期之内要多几个不容易，全部写在表里更简单。
至于国外的那些个，我想先解决 GFW 再说吧。

user_extends 看似简单，但一个用户有10项个人资料就要写入10行，表行数暴增不说，取出后再处理10遍也是够够的了，话说一个用户10项个人资料不算多吧？

一是真有这么多扩展吗？
二是考虑这么多的扩展，用 NoSQL 不好吗？用 MongoDB 之类的文档数据库不行吗？干吗非要往关系型数据库上堆呢？

个人意见。

@qufo 这是一个系统规模的问题。

@Handle 我也是用同样的方式，不过我不是用多个controller处理不同的登录终端，只请求头里加个字段区分而已

学习了

@Handle 能晒出具体表结构吗？感觉这样的设计还是比较好

@cboy868
---------------------DDL-------------------
create table biz_users
(
id serial not null
constraint biz_users_pkey
primary key,
user_id integer not null,
user_type varchar(255) not null,
deleted_at timestamp(0),
created_at timestamp(0),
updated_at timestamp(0)
)
;

create table wechat_mini_program_accounts
(
id serial not null
constraint wechat_users_pkey
primary key,
open_id varchar(255) not null
constraint wechat_users_open_id_unique
unique,
deleted_at timestamp(0),
created_at timestamp(0),
updated_at timestamp(0),
name varchar(255),
avatar varchar(255)
)
;

create table wechat_official_accounts
(
id serial not null
constraint wechat_official_accounts_pkey
primary key,
open_id varchar(255) not null
constraint wechat_official_accounts_open_id_unique
unique,
name varchar(255),
avatar varchar(255),
is_valid boolean default true not null,
unionid varchar(255),
is_preview_user boolean default false not null,
created_at timestamp(0),
updated_at timestamp(0),
deleted_at timestamp(0)
)
;
---------------------DDL-------------------

class BizUser extends Model
{
use SoftDeletes;
protected $guarded = ['id'];
public function user()
{
return $this->morphTo();
}
}

把手机号和密码，直接放到oauths中，是不是更好点呢，用户表只存基准数据，不做登录相关的处理

@大业 也是可以的，我这边主要是把手机号密码登陆作为主要登陆场景，所以这么操作啦