196 lines
7.0 KiB
Markdown
196 lines
7.0 KiB
Markdown
# 商城系统用户表兼容性分析报告
|
||
|
||
## 一、现有 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. 地址表设计需求
|
||
|
||
```sql
|
||
-- 用户地址表
|
||
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. **新增商城扩展表**:
|
||
```sql
|
||
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` 管理商城角色
|
||
- 应用层根据业务模块使用相应角色字段
|
||
|
||
#### 优势:
|
||
- ✅ 最大化复用现有基础设施
|
||
- ✅ 避免核心用户表的破坏性修改
|
||
- ✅ 商城业务数据独立可控
|
||
- ✅ 支持用户在两套系统间自由切换
|
||
- ✅ 便于后续扩展其他业务模块
|
||
|
||
这种方案既保护了现有运动平台的稳定性，又为商城系统提供了完整的用户管理能力，是最佳的平衡方案。
|