CRM相关库表设计

一、核心业务实体表

这类表是CRM的基石,存储着最基本的业务对象。

1. 客户表 (Customer / Account)

存放客户的基本信息。需要注意:ToB(企业对企业)和ToC(企业对消费者)业务的结构略有不同,这里展示一个通用的简化结构。

字段名 类型 说明
customer_id INT (PK) 客户唯一ID
customer_name VARCHAR 客户名称(个人姓名或企业名)
phone VARCHAR 联系电话
email VARCHAR 邮箱
source VARCHAR 客户来源(广告、转介绍、展会等)
industry VARCHAR 所属行业(ToB常见)
customer_type ENUM 潜在客户 / 现有客户 / 已流失
owner_id INT (FK) 负责人ID(关联员工表)
created_at DATETIME 创建时间
2. 员工/用户表 (User / Employee)

谁在用这个系统?通常是公司的销售或客服人员。

字段名 类型 说明
user_id INT (PK) 员工唯一ID
name VARCHAR 姓名
department VARCHAR 所属部门(销售部、市场部)
role VARCHAR 角色(管理员、普通销售、销售经理)
3. 产品表 (Product)

公司卖什么东西?

字段名 类型 说明
product_id INT (PK) 产品唯一ID
product_name VARCHAR 产品名称
model VARCHAR 型号/规格
price DECIMAL 标准售价
cost DECIMAL 成本(用于计算利润)

二、关联/过程实体表

这部分是CRM的灵魂,记录了围绕客户发生的所有动态事件。

4. 销售线索表 (Lead)

这是最早的潜在客户信息,往往来自市场活动,还不一定是真正的客户。

字段名 类型 说明
lead_id INT (PK) 线索唯一ID
company VARCHAR 公司名称
contact_person VARCHAR 联系人
status ENUM 新建 / 已分配 / 跟进中 / 已转化 / 已流失
converted_customer_id INT (FK) 转化后的客户ID(线索成功转为客户时关联)
5. 商机表 (Opportunity)

代表一个具体的销售机会。比如:向XX公司销售XX产品,预计金额XX万。这是销售漏斗的核心。

字段名 类型 说明
opp_id INT (PK) 商机唯一ID
opp_name VARCHAR 商机名称
customer_id INT (FK) 关联客户表
stage ENUM 销售阶段(初步接洽 / 需求分析 / 方案报价 / 谈判 / 赢单 / 输单)
amount DECIMAL 预计成交金额
close_date DATE 预计签单日期
product_id INT (FK) 意向产品
6. 跟进记录表 (Activity / Interaction)

记录销售给客户打的每一通电话、发的每一封邮件。这张表往往数据量最大。

字段名 类型 说明
activity_id INT (PK) 活动ID
customer_id INT (FK) 关联客户
user_id INT (FK) 跟进人(销售)
type ENUM 电话 / 邮件 / 会议 / 微信
content TEXT 沟通内容摘要
next_step VARCHAR 下一步行动计划
next_time DATETIME 下次联系时间
7. 订单/合同表 (Order / Contract)

成交后的结果。

字段名 类型 说明
order_id INT (PK) 订单ID
customer_id INT (FK) 关联客户
opp_id INT (FK) 关联商机(可选)
total_amount DECIMAL 合同总金额
sign_date DATE 签订日期
status ENUM 执行中 / 已完成 / 已终止

三、配置/辅助实体表

8. 字典表 (Sys_Dict)

用于存储下拉菜单选项,如商机阶段、客户来源、行业类型等。方便程序扩展,修改选项时不用改代码。

字段名 类型 说明
dict_id INT (PK) 字典ID
type VARCHAR 类型(如:lead_source)
code VARCHAR 选项编码(如:001)
value VARCHAR 选项值(如:百度广告)
sort_order INT 排序

四、关键关联关系图解

为了帮助你更直观地理解,这些表之间的逻辑关系如下:

  • 销售线索(Lead) -> 客户(Customer):一个线索转化后生成一个客户。

  • 客户(Customer) -> 商机(Opportunity):一个客户可以有多个正在进行的销售机会。

  • 客户(Customer) -> 跟进记录(Activity):一个客户对应多条跟进记录。

  • 客户(Customer) -> 订单(Order):一个客户可以有多次购买(多个订单)。

  • 员工(User) :所有的客户、商机、跟进记录通常都需要有一个owner_id(负责人ID),以此来实现数据权限(每个销售只能看到自己的客户)。

五、设计时的注意事项

  1. 字段冗余设计 :在报表查询量大的场景下(如统计合同金额),有时会在订单表中冗余存储客户名称或产品名称,以减少多表关联查询,提高速度(即反范式设计)。

  2. 软删除 :不要物理删除客户数据(DELETE FROM customer),通常增加一个status字段(如:正常/已删除)来标记,否则会丢失历史分析数据。

  3. 自定义字段 :现代CRM系统往往需要预留扩展能力。通常会预留text1、text2、int1等备用字段,或者设计单独的自定义字段表来满足不同企业的个性化需求。

相关推荐
要开心吖ZSH1 小时前
一次线上锁风暴复盘:号源表大范围 DELETE 的隐患与分批删除改造
数据库·mysql·行锁·1024程序员节·间隙锁·lockwaittimeout
l1t2 小时前
在windows中测试musql数据库
数据库·sqlite·go·1024程序员节
鬼手点金3 小时前
从 API 消息到模型 Token:Chat Template
java·前端·javascript·数据库·人工智能·深度学习·1024程序员节
CRMEB系统商城3 小时前
Redis + 消息队列 + 连接池:CRMEB PRO 性能优化的三驾马车
大数据·数据库·人工智能·小程序·php·1024程序员节
鸽芷咕3 小时前
KingbaseES SQL 调优六步法:定位、诊断、下药、验证,一步都别省
数据库
黄俊懿4 小时前
【架构师从入门到进阶】第七章:缓存和存储的优化思路——第一节:缓存概述
数据结构·数据库·分布式·缓存·架构·系统架构·1024程序员节
John_Hui4 小时前
MySQL 进阶知识
数据库·sql·mysql·1024程序员节
java_nnnn4 小时前
Redis 核心特性与应用场景:从底层原理到分布式系统应用
数据库·redis·1024程序员节
Random Glow4 小时前
一条 SQL 从输入到返回,中间经历了什么
数据库·后端·mysql·性能优化·innodb·1024程序员节
何中应4 小时前
MySQL 连接驱动单独下载的两种方式
数据库·mysql·maven