akmon/doc_mall/analysis/user_compatibility_analysis.md

商城系统用户表兼容性分析报告

一、现有 ak_users 表结构分析

1. 核心字段对比

字段名	运动平台用途	商城系统需求	兼容性	备注
id	用户唯一标识	用户唯一标识	✅ 完全兼容	UUID主键
username	用户名	用户名	✅ 完全兼容	VARCHAR(64)
email	邮箱	邮箱	✅ 完全兼容	VARCHAR(128)
password_hash	密码哈希	密码哈希	✅ 完全兼容	VARCHAR(256)
phone	手机号	手机号	✅ 完全兼容	VARCHAR(32)
avatar_url	头像	头像	✅ 完全兼容	TEXT
created_at	创建时间	创建时间	✅ 完全兼容	TIMESTAMP
updated_at	更新时间	更新时间	✅ 完全兼容	TIMESTAMP

2. 运动平台特有字段

字段名	用途	商城系统影响	处理建议
gender	性别	🔄 可选利用	商城可用于个性化推荐
birthday	生日	🔄 可选利用	可用于会员生日营销
height_cm	身高	❌ 不相关	保留但不使用
weight_kg	体重	❌ 不相关	保留但不使用
bio	个人简介	🔄 可选利用	可用于用户展示
region_id	所属地区	🔄 部分兼容	可用于配送区域判断
school_id	所属学校	❌ 不相关	对商城无意义
grade_id	所属年级	❌ 不相关	对商城无意义
class_id	所属班级	❌ 不相关	对商城无意义
role	用户角色	⚠️ 冲突风险	需要扩展支持商城角色

3. 商城系统缺少字段

字段名	商城需求	解决方案
user_type	用户类型(消费者/商家/配送员)	扩展 role 字段或新增字段
status	用户状态(正常/冻结/注销)	新增字段
real_name	真实姓名	新增字段(商家认证、配送员等需要)
id_card	身份证号	新增字段(商家/配送员认证)

二、地址表缺失分析

1. 现状

• ❌ 运动平台没有专门的用户地址表
• ❌ 商城系统必需收货地址管理功能
• 订单中 delivery_address 字段使用 JSONB 存储，缺乏结构化管理

2. 地址表设计需求

-- 用户地址表
CREATE TABLE public.ak_user_addresses (
    id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id uuid REFERENCES public.ak_users(id) ON DELETE CASCADE,
    receiver_name VARCHAR(64) NOT NULL, -- 收货人姓名
    receiver_phone VARCHAR(32) NOT NULL, -- 收货人手机
    province VARCHAR(64) NOT NULL, -- 省份
    city VARCHAR(64) NOT NULL, -- 城市
    district VARCHAR(64) NOT NULL, -- 区县
    address_detail TEXT NOT NULL, -- 详细地址
    postal_code VARCHAR(16), -- 邮编
    is_default BOOLEAN DEFAULT false, -- 是否默认地址
    label VARCHAR(32), -- 地址标签(家/公司/学校等)
    coordinates POINT, -- 经纬度坐标
    created_at TIMESTAMP WITH TIME ZONE DEFAULT now(),
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT now()
);

三、兼容性问题分析

1. 高风险冲突 ⚠️

A. 角色系统冲突

• 运动平台角色: student, teacher, admin 等教育相关
• 商城系统角色: consumer, merchant, delivery, service, admin 等商务相关
• 解决方案:
  • 方案1: 扩展 role 字段支持多系统角色 (sport_student, mall_consumer)
  • 方案2: 新增 system_roles JSON字段存储多系统角色映射
  • 方案3: 创建独立的用户角色关联表

B. 业务逻辑冲突

• 运动平台: 强绑定学校/班级体系，基于教育场景
• 商城系统: 基于地理位置和商业场景，无教育概念
• 影响: 数据查询、权限控制、业务流程存在根本差异

2. 中等风险问题 🔄

A. 数据完整性

• 运动平台用户可能缺少商城必需信息(真实姓名、身份认证)
• 商城用户可能不需要运动平台的教育信息
• 解决方案: 建立数据补全机制和可选字段策略

B. 性能影响

• 单表存储两套业务数据，查询条件复杂
• 索引策略需要同时优化两套业务场景
• 解决方案: 合理设计索引，考虑分区表或读写分离

3. 低风险问题 ✅

A. 基础字段兼容

• 用户基本信息(用户名、邮箱、手机、头像)完全兼容
• 认证体系(password_hash, auth_id)可共用
• 时间字段(created_at, updated_at)格式一致

四、推荐方案

方案1: 共用方案(推荐度: ⭐⭐⭐)

优点:

• 用户账号统一，单点登录
• 减少数据冗余
• 开发成本相对较低

缺点:

• 业务耦合度高
• 角色系统复杂
• 性能优化困难

实施步骤:

1. 扩展 ak_users 表字段
2. 创建 ak_user_addresses 地址表
3. 设计多系统角色管理机制
4. 建立数据迁移和兼容策略

方案2: 独立方案(推荐度: ⭐⭐⭐⭐⭐)

优点:

• 业务隔离，各自优化
• 扩展性强，维护简单
• 避免相互影响

缺点:

• 需要账号同步机制
• 数据可能冗余
• 初期开发成本高

实施步骤:

1. 创建独立的商城用户表 mall_users
2. 创建商城地址表 mall_user_addresses
3. 建立账号同步/关联机制
4. 设计跨系统数据共享策略

方案3: 混合方案(推荐度: ⭐⭐⭐⭐)

优点:

• 核心用户信息共用
• 业务特定数据隔离
• 平衡复杂度和效率

实施策略:

• 共用 ak_users 核心用户表
• 创建 mall_user_profiles 商城用户扩展表
• 创建 mall_user_addresses 商城地址表
• 通过 user_id 关联，实现业务数据隔离

五、最终建议

🎯 强烈推荐：方案3(混合方案)

实施细节:

1. 保持 ak_users 表不变，作为用户主表

2. 新增商城扩展表:

   CREATE TABLE public.mall_user_profiles (
       id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
       user_id uuid UNIQUE REFERENCES public.ak_users(id) ON DELETE CASCADE,
       user_type INTEGER DEFAULT 1, -- 1消费者 2商家 3配送员
       status INTEGER DEFAULT 1, -- 1正常 2冻结 3注销
       real_name VARCHAR(64), -- 真实姓名
       id_card VARCHAR(32), -- 身份证号
       credit_score INTEGER DEFAULT 100, -- 信用分数
       mall_role VARCHAR(32) DEFAULT 'consumer', -- 商城角色
       created_at TIMESTAMP WITH TIME ZONE DEFAULT now(),
       updated_at TIMESTAMP WITH TIME ZONE DEFAULT now()
   );
   

3. 创建地址表 ak_user_addresses(如上设计)

4. 角色管理策略:

   • ak_users.role 保持运动平台角色
   • mall_user_profiles.mall_role 管理商城角色
   • 应用层根据业务模块使用相应角色字段

优势:

• ✅ 最大化复用现有基础设施
• ✅ 避免核心用户表的破坏性修改
• ✅ 商城业务数据独立可控
• ✅ 支持用户在两套系统间自由切换
• ✅ 便于后续扩展其他业务模块

这种方案既保护了现有运动平台的稳定性，又为商城系统提供了完整的用户管理能力，是最佳的平衡方案。