企业官网建设流程全解析

简介：客户管理系统ER图文档面向数据库设计初学者与软件工程课程学生，以可视化的方式讲解实体-关系模型的核心概念，能帮助读者快速建立从业务需求到概念模型的映射思路。文档以客户、订单、产品三个典型实体为线索，逐一说明客户编号、姓名、地址、电话号码以及订单编号、下单日期、产品价格等属性字段，并清晰对比客户与订单、订单与产品之间的一对多关系，同时覆盖ER图在数据库设计、软件建模与业务流程梳理中的典型应用场景。文档还阐述了这种模型的突出优点，如便于团队理解和沟通、为物理表结构设计提供清晰蓝图，以及有助于保障数据模型规范一致。资源包体非常精简，仅有1个doc文档，约184KB，内容集中，阅读门槛低，适合零基础入门或课程设计前期快速参考。目前已有604人学习，读者可对照其中实体、属性和关系的定义，自行推导客户下单场景的表结构，加深对ER图实用价值的理解。

1. 客户管理系统ER图：为什么看似最普通的图，最能暴露系统设计功力

一份名为“客户管理系统ER图”的文档，在很多开发者眼里不过是几张画着方框和连线的草图。但实际上，ER图是客户管理系统从零到一最关键的地基：实体划分错，后端的表结构就歪；关系基数标错，业务逻辑写起来处处别扭；主键选错，上线半年后数据归档和同步就会变成灾难。我见过太多项目在最简单的“客户”两个字上翻车——把“客户”和“联系人”混成一张表，或者把“客户—产品”直接画成多对多，结果订单、合同、跟进记录全都无处安放。这篇笔记就是要讲清楚一件事：怎么把客户管理系统背后真正的实体和关系画对、落地成表、并且避开那些只有踩过坑才看得见的细节。适合正在做课程设计、刚接手企业管理系统开发、或者准备重构老系统数据库的从业者。

2. 识别核心实体：客户、联系人、商机之间的边界在哪

2.1 客户不等于联系人：一张表装两个身份是第一种错误

客户管理系统里最常见的实体其实有五个：客户、联系人、商机（或订单）、产品、跟进记录。初学者最常犯的错误，就是把“客户”和“联系人”合并成一张表，字段里既放公司名称、公司地址，又放联系人姓名、手机号。短期看倒是省事，一旦同一个公司有多个联系人，数据就开始失控：联系人A离职了要删掉联系方式，结果公司主体的地址和行业信息也被误删；老板想把同一个公司的两个联系人关联到同一个客户下，发现表结构根本不支持这种一对多关系。

正确的做法是把客户和联系人拆成两张表。客户表存的是组织或个人的稳定属性——公司名称、所属行业、客户规模、来源渠道、注册地址；联系人表存的是人的属性——姓名、职位、手机、微信、邮箱、喜好备注。两张表通过外键关联：一个客户可以挂多个联系人，每个联系人必须归属一个客户。为什么必须拆？因为客户这个实体在ERP、CRM、财务系统里是“开票主体”和“收款主体”，而联系人是“沟通对象”和“跟进对象”，两者生命周期完全不同：客户会被标记为“流失”，联系人可能只是离职了。如果你把这两个生命周期塞进一张表，任何一个状态变更都会污染另一个维度。

字段设计上，我一般会给出这样一组最小集：

• 客户表：customer_id（主键）、customer_name、industry、customer_level、source_channel、status、created_at、updated_at
• 联系人表：contact_id（主键）、customer_id（外键）、contact_name、position、mobile、wechat、email、is_primary

其中is_primary标记是否为主要联系人，用于列表页默认展示。为什么需要这个标记？因为企业在打电话、发邮件时通常会找个“默认联系人”，你总不能每次都在代码里ORDER BY created_at LIMIT 1，那属于把业务决策漏在SQL里。

2.2 关系和基数的确认：用订单把“多对多”拆成“一对多”

再往后是客户和产品的关系。直觉上，客户可以买多种产品，产品可以被多个客户购买，所以画一个“多对多”关系。这个直觉不能说错，但它不适合直接落表。多对多关系在关系型数据库里的落法必然要拆出一张中间表，而中间表恰恰就是业务实体——订单表（或商机表）。

订单表天然拥有自己的属性：下单时间、产品数量、成交单价、总金额、折扣、支付状态、交付状态。如果直接画客户—产品多对多，这些属性放哪？放在关联表里勉强能塞，但语义上很别扭：关联表变得既描述关系又携带行为数据，查询“某个客户买过多少种产品”时，每次都要过滤订单状态，逻辑上会越绕越糊涂。

所以客户管理系统ER图里，标准做法是：

• 客户 1—N 订单
• 产品 1—N 订单明细（或直接 1—N 订单，每张订单只买一个产品的情况可以省一张表）

为什么订单要单独拎出来？因为你要统计的很多指标都以订单为粒度：本月成交额、某销售负责的订单数、平均客单价。如果你把订单放在关联表里，这些统计会变成一堆GROUP BY加上JOIN，而订单自身的状态字段（待支付、已支付、已取消）就无处安放。ER图的本质是帮你想清楚“哪些数据有自己的生命周期和属性”，想清楚了，表结构自然就清楚了。

2.3 跟进记录和操作日志：不要一开始就画进ER图

新手画ER图时容易把系统里所有数据一股脑画进去，包括跟进记录、操作日志、登录日志。我的建议是：第一版ER图只画核心业务实体和关系，跟进记录和日志这类数据可以在设计时单独加一个“支撑数据”区标注，但不要和客户、订单并列成同级实体。

原因有二。第一，跟进记录的数据量级和核心实体完全不同——一个客户一年可能有几十条跟进，但只有一条客户主数据。两者混在一张ER图里会让连线变得混乱，阅读者分不清主次。第二，跟进记录和订单在查询模式上完全不同：跟进记录往往是“按客户查最近一条”或“按销售查今日任务”，它是流水型数据，而客户、订单是状态型数据。流水型数据通常有独立的归档策略（比如按季度分表或冷热分离），和核心实体混在同一张图上会误导表设计。

3. 把ER图画出来：属性、主键标记与工具的选用

3.1 主键选择：自增ID、UUID还是业务唯一键

画ER图时每个实体都要标主键。主键选型直接决定你后面要不要花大力气做数据迁移。三种主流方案各有利弊：

客户管理系统里我通常推荐自增ID加一个业务编号字段的组合方案：customer_id做主键用于关联，customer_no做业务编号展示给用户。为什么不用业务编号直接做主键？因为业务编号有可能会变——比如公司合并后客户编号体系重排。一旦业务编号作为外键被其他表引用，改编号就要级联更新所有关联表，属于典型的“改动一处、崩掉一片”。用自增ID做主键，业务编号想怎么改都行，不影响关联关系。

UUID方案客户管理系统里用得少，除非你的系统要支持多端离线创建客户，比如销售在外网断网时先用本地草稿箱创建客户、联网后再同步。这种场景下自增ID没法做，因为不同端生成的主键会冲突，只能换UUID。代价是关联表里的外键字段也要一并改成UUID，存储空间和索引性能都会吃亏。

3.2 ER图工具选择：从纸笔到代码生成

画ER图的工具有很多种，常见的有：MySQL Workbench的EER图、draw.io、PlantUML、dbdiagram.io，还有老牌工具PowerDesigner（如果公司有正版授权的话）。我的建议是：如果ER图最终要指导建表，选能用代码生成DDL的工具；如果只是做设计方案评审，draw.io足够。

为啥？因为手画的ER图和最终的建表SQL之间存在一道鸿沟——手画图画得再漂亮，字段类型、默认值、字符集、索引这些信息还是得挨个填进SQL。用dbdiagram.io或MySQL Workbench这类工具可以在ER图上直接定义字段类型和约束，工具会自动生成DDL脚本，省去手工翻译的环节，也减少“图上标了not null、建表语句里漏了”这种低级不一致。

下面是用类SQL的DSL描述客户表的一个典型片段（类似dbdiagram.io语法）：

Table customer { customer_id int [pk, increment] customer_no varchar(20) [not null, unique] customer_name varchar(100) [not null] industry varchar(50) [null] customer_level varchar(10) [null, default: 'C'] source_channel varchar(30) [null] status tinyint [not null, default: 1] created_at datetime [not null, default: `CURRENT_TIMESTAMP`] updated_at datetime [not null, default: `CURRENT_TIMESTAMP`] } Table contact { contact_id int [pk, increment] customer_id int [ref: > customer.customer_id, not null] contact_name varchar(50) [not null] mobile varchar(20) [null] is_primary tinyint [not null, default: 0] }

这段描述里每个字段后面的方括号就是这个字段的约束标记。pk表示主键，increment表示自增，ref: > customer.customer_id表示外键，指向customer表的customer_id。为什么用>而不是普通连线？因为它明确表示“多对一”——多个联系人指向同一个客户，这正是前面强调的边界划分。

字段默认值的设置也有讲究：status默认1表示启用，customer_level默认'C'表示最低等级客户。这些默认值不是随便给的，它们对应着业务规则：新客户进来默认是普通等级，默认是可跟进状态。ER图阶段就把默认值定下来，后面业务代码里就不会出现“为什么新建的客户没有状态”这种问题。

4. 客户管理系统ER图设计避坑：5个真实翻车现场

4.1 把“客户”和“联系人”做成一张表

现象：系统上线后，同一个公司有3个联系人，销售想给其中一个联系人单独记一条跟进备注，结果每次保存都覆盖整个客户的信息。排查发现客户表和联系人表是同一张表，每个联系人一行记录，公司信息被重复存了3份。

原因：设计阶段没分清“客户”和“联系人”是两个生命周期独立的实体。客户生命周期是“潜在—跟进—成交—流失”，联系人生命周期是“在职—离职”，如果两张表混在一起，联系人的离职状态会连带触发客户流失状态的变化。

解决：把联系人拆成独立表，挂到客户表下。改动涉及三处——新表建立、原表数据迁移、业务代码中查询客户详情的SQL改为两表关联查询。迁移时要注意客户主表保留一条主记录，联系人表按原表的每个人一条插入。

4.2 主键用了手机号，客户换号后全线崩溃

现象：联系人手机号被设为主键，某重点客户的采购经理换了手机号，系统里所有关联的跟进记录、订单记录全部查不出来，因为外键还是旧的手机号。

原因：把自然键（业务上有意义的字段）当主键用，忽视了业务字段会变化的可能性。

解决：所有表改用自增ID作为主键，手机号和邮箱作为普通字段，加唯一索引即可。历史数据需要先更新外键关联表，把旧手机号批量替换为新手机号，再放开手机号字段的唯一索引约束。

4.3 客户和产品直接多对多连线，订单数据无处安放

现象：ER图上画了“客户—产品”多对多关系，开发时发现下单时间、支付状态、折扣金额没有字段存。最终把订单时间和数量塞进关联表，导致关联表越写越臃肿——既当关联关系，又当业务单据。

原因：没能识别出“多对多关系”背后的中间实体。客户购买产品这个动作，本质上是一次交易行为，而交易行为有独立的属性和生命周期。

解决：在客户与产品之间增加订单实体。如果一张订单可能包含多个产品，再加订单明细表；如果业务简单，一张订单只买一个产品，订单表可以直接外键引用产品和客户。

4.4 没有设计软删除，误删客户后历史数据全丢

现象：运营人员在客户管理界面误删了一个客户，结果这个客户名下的所有跟进记录和订单在系统里全部消失。虽然数据库有每日备份，但恢复要找回指定时间点的数据，操作了整整半天。

原因：ER图里没有设计status或is_deleted字段，删除操作执行了物理DELETE。

解决：所有核心业务表增加status字段（应用层约定只标记删除为某个特定值，比如2），查询语句默认过滤删除状态。ER图上也要把这个字段画进去，并注明“逻辑删除标志”。物理删除只允许在管理员手动清理孤儿数据时使用。

4.5 无视时区问题，客户创建时间差8小时

现象：客户管理列表里显示某客户创建时间是凌晨4点，产品经理想知道这是哪个时段注册的。排查发现数据库存的是UTC时间，应用层取出后没有做时区转换，直接输出给前端。

原因：ER图阶段定义了字段类型为datetime，但没有约定存储时区规则。数据库默认时区是UTC，应用服务器默认时区也是UTC，前端展示时没有转换，于是所有时间落后8小时。

解决：ER图上统一标注时间字段使用datetime+ 时区，或者直接约定所有时间字段在应用层统一转为ISO8601字符串存储。更稳妥的做法是利用数据库的timestamp类型，它会自动按会话时区转换显示。注意播种：历史数据要写一个一次性脚本对所有时间字段按旧时区偏移量做修正，否则新旧数据之间会存在8小时差值。

5. 从ER图到建表：一份可以直接抄的客户管理库DDL

5.1 核心五张表的建表语句与字段说明

当ER图画清楚之后，下一步就是把它翻译成真实的表结构。下面是一份适合中小型客户管理系统的MySQL DDL。这套结构覆盖了客户、联系人、订单、产品、跟进记录五个核心实体，字段命名和类型都按上线标准来。

-- 客户表 CREATE TABLE customer ( customer_id INT UNSIGNED AUTO_INCREMENT COMMENT '客户ID，主键', customer_no VARCHAR(20) NOT NULL COMMENT '客户编号（业务展示用）', customer_name VARCHAR(100) NOT NULL COMMENT '客户名称', industry VARCHAR(50) DEFAULT NULL COMMENT '所属行业', customer_level CHAR(1) DEFAULT 'C' COMMENT '客户等级：A/B/C', source_channel VARCHAR(30) DEFAULT NULL COMMENT '来源渠道', status TINYINT NOT NULL DEFAULT 1 COMMENT '状态：1启用，2删除', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (customer_id), UNIQUE KEY uk_customer_no (customer_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='客户主表';

这条DDL里面有三个容易被忽略的细节。第一个是customer_no上面挂了唯一索引，也就是说即使主键是自增ID，业务编号仍然不能重复，这是为了防止人工录入错误导致重复客户。第二个是status字段用TINYINT而不是VARCHAR，因为状态在代码里是一个枚举，用数值类型更省空间且避免拼写不一致。第三个是created_at和updated_at的默认值，前者固定当前时间，后者加了ON UPDATE关键字，这样每次UPDATE时数据库会自动刷新更新时间，不需要应用层手动维护。

-- 联系人表 CREATE TABLE contact ( contact_id INT UNSIGNED AUTO_INCREMENT COMMENT '联系人ID，主键', customer_id INT UNSIGNED NOT NULL COMMENT '所属客户ID，外键', contact_name VARCHAR(50) NOT NULL COMMENT '联系人姓名', position VARCHAR(50) DEFAULT NULL COMMENT '职位', mobile VARCHAR(20) DEFAULT NULL COMMENT '手机号', wechat VARCHAR(50) DEFAULT NULL COMMENT '微信号', email VARCHAR(100) DEFAULT NULL COMMENT '邮箱', is_primary TINYINT NOT NULL DEFAULT 0 COMMENT '是否主要联系人：0否，1是', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (contact_id), KEY idx_customer_id (customer_id), CONSTRAINT fk_contact_customer FOREIGN KEY (customer_id) REFERENCES customer (customer_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='联系人表';

联系人表的关键在于fk_contact_customer这个外键约束。外键有两个作用：一是防止插入不存在的customer_id，二是防止删除有联系人的客户。第二个作用在实际业务中经常被嫌弃——比如清理测试客户时会因为外键约束报错。我的经验是：外键约束在开发阶段建议保留，上线后如果确定应用层已经处理了关联校验，可以移除外键只保留索引，删数据时会更灵活。但这个决定要在ER图上注明“物理外键已移除，逻辑关系仍在”。

5.2 订单和跟进记录的选择：中间表还是独立实体

-- 订单表 CREATE TABLE orders ( order_id INT UNSIGNED AUTO_INCREMENT COMMENT '订单ID', order_no VARCHAR(30) NOT NULL COMMENT '订单编号', customer_id INT UNSIGNED NOT NULL COMMENT '客户ID', product_id INT UNSIGNED NOT NULL COMMENT '产品ID', quantity INT NOT NULL DEFAULT 1 COMMENT '购买数量', unit_price DECIMAL(10,2) NOT NULL COMMENT '成交单价', total_amount DECIMAL(10,2) NOT NULL COMMENT '订单总金额', order_status TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0待支付，1已支付，2已取消', order_time DATETIME NOT NULL COMMENT '下单时间', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (order_id), KEY idx_customer_id (customer_id), KEY idx_order_time (order_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';

订单表的字段设置上要特别注意unit_price和total_amount用DECIMAL(10,2)而不是FLOAT或DOUBLE。浮点数在计算金额时有精度问题，比如0.1+0.2算出来是0.30000000000000004，金额差一分钱在财务对账时就是灾难。DECIMAL是定点数，按小数位精确存储，每次计算都不会丢精度。另一个细节是order_time单独挂了索引，因为客户管理系统的统计报表十有八九要按时间范围查订单。

跟进记录表设计成一个独立的流水表，不挂外键约束，因为它的查询模式是“按客户查最近一条”，外键约束在这里只会拖累插入速度。

6. 再进一步：把ER图扩展成可持续演进的客户数据结构

6.1 给所有表加审计字段，相当于给数据上了后悔药

客户管理系统的数据，最怕的是出了问题查不到源头：这条数据谁创建的？什么时候改的？之前的值是什么？开发阶段可以忽略这些问题，一旦业务跑起来，运营、销售、财务都会拿着问题来找你。

所以我在做客户管理系统的ER图时，会在每个核心实体上额外加一组审计字段：created_by、updated_by。前者记录创建人，后者记录最后修改人。具体存储上可以存用户ID（关联用户表），也可以直接存用户名。考虑到用户ID可能被删除导致无法关联，我倾向于存用户名，虽然会多一点冗余，但查问题时不需要级联查询用户表。

这组字段的最直接用法是排查数据争议。比如销售说“这条跟进不是我写的”，你查updated_by就能知道最后是谁改的。又比如客户级别从A被改成了C，查updated_at定位时间点，再配合操作日志表能还原出整个操作链路。

6.2 用B树索引还是全文索引：按查询场景逆推索引设计

客户管理系统里最常见的查询是：按客户名称模糊搜索、按联系人手机号精确搜索、按客户等级和来源渠道组合筛选。这些查询考察的是索引设计，而不是ER图本身，但ER图的字段定义直接决定了索引能不能建得有效。

customer_name字段如果要做模糊搜索，LIKE '%关键字%'无法走索引，全表扫描是必然。如果数据量在一万行以内，这个代价可以接受。如果数据量去到几十万行，就得考虑用全文索引或者外部的搜索引擎组件。ER图设计阶段我会标注哪些字段会被用于模糊查询，这样在选字段类型时会把customer_name设为VARCHAR(100)而不是TEXT，因为TEXT类型无法直接加普通索引的默认前缀长度，需要特殊处理。

手机号搜索则适合建普通索引，因为它是等值查询，区分度高。组合筛选（等级+来源渠道）应该建联合索引，索引顺序按区分度从高到低排列。这个顺序不能拍脑袋，要在日志或测试数据里统计出“哪个条件筛掉的行数最多”，比如客户等级只有三个值，区分度低，来源渠道可能有几十个值，区分度高，那联合索引就该是(source_channel, customer_level)。

6.3 从ER图到物理模型的数据字典：一张值得长期维护的表

ER图画完之后，真正长期陪伴系统的是数据字典。我的习惯是维护一张文档风格的数据字典表格，字段名、类型、默认值、是否为空、业务含义一一对应。这个数据字典的好处在于：新同学接手项目不需要打开数据库挨个看字段注释，业务方提需求时也能直接根据字段名进行对接。

数据字典的常用格式如下：

这些字段的含义解释要具体到“取值是什么含义”，不要写“状态字段”这种谁都能看懂但谁都不明白的废话。比如status的业务含义必须明确写出“1=启用、2=逻辑删除”，避免后来者猜。

回顾整个客户管理系统的数据结构设计，我最深的体会是：ER图不是一个交付物，而是一个思考工具。画图的本质是在逼自己想清楚每个数据对象有没有独立生命周期、每对关系之间是强约束还是弱依赖。我自己也曾经跳过ER图直接建表，结果表建完发现客户和订单之间漏了索引，查询越来越慢，最后还是回到画图重新捋关系。现在凡是做管理系统，哪怕是内部工具，我都会先花半小时把ER图和字段清单列出，这个习惯建议你保留，希望帮到你。

本文还有配套的精品资源，点击获取