数据库设计基础回顾：关系型数据库核心概念

各位同学，咱们今天聊点基础但极其重要的东西。说实话，我见过太多CRM项目翻车，根源往往不是业务逻辑多复杂，而是最基础的数据库设计就没站稳。你想想看，地基歪了，楼能盖多高？

这一章，我带大家快速过一遍关系型数据库的核心概念。别觉得简单，我敢打赌，有些细节你平时真没注意过。

表、字段、主键、外键——数据库的“四块砖”

表（Table），说白了就是一张二维的电子表格。每一行是一条记录，每一列是一个属性。在CRM系统里，客户表、订单表、产品表，这些都是最典型的例子。

字段（Field），就是列。我个人的习惯是，字段命名一定要见名知意。比如客户表里，customer_name 比 name 好，created_at 比 time 好。为什么？因为半年后你回头看SQL，不用猜。

主键（Primary Key），是每行数据的唯一身份证。我建议用自增整数或者UUID。但注意，在CRM这种高并发场景下，UUID虽然全局唯一，但插入性能不如自增ID。我在一个千万级客户的系统里踩过这个坑——UUID做主键，索引碎片化严重，查询慢得让人抓狂。

外键（Foreign Key），是表与表之间的“钩子”。比如订单表里的 customer_id，指向客户表的主键。嗯，这里要注意：外键能保证数据完整性，但也会降低写入性能。我在实际项目中，通常只在核心业务表之间保留外键约束，非核心表靠应用层逻辑保证。

ER图绘制方法——把业务“画”出来

ER图（实体-关系图），是数据库设计的“蓝图”。我每次接手新项目，第一件事不是写SQL，而是画ER图。为什么？因为画图的过程，就是梳理业务逻辑的过程。

画ER图，记住三个要素：

• 实体（Entity）：用矩形表示，比如“客户”、“订单”。
• 属性（Attribute）：用椭圆表示，比如客户的“姓名”、“电话”。
• 关系（Relationship）：用菱形表示，比如“客户”和“订单”之间的“下单”关系。

关系有三种类型：

• 一对一（1:1）：一个客户对应一个会员卡号。少见，但存在。
• 一对多（1:N）：一个客户可以有多个订单。这是最常见的。
• 多对多（M:N）：一个产品可以属于多个分类，一个分类包含多个产品。需要拆成两张表加一张关联表。

我曾经犯过一个低级错误：把多对多关系直接用一个字段存逗号分隔的ID。结果查询时要用 FIND_IN_SET，性能差到离谱。后来老老实实拆成关联表，世界清净了。

范式理论（1NF、2NF、3NF）——设计的“红绿灯”

范式，说白了就是数据库设计的规范。不遵守，数据会冗余、更新会异常、删除会丢数据。但过度遵守，查询性能会下降。所以，要懂，但别死板。

第一范式（1NF）：字段不可再分

每个字段只能存一个值。比如“地址”字段，不能写成“北京市海淀区中关村大街1号”，而应该拆成“省份”、“城市”、“详细地址”。

我在一个老CRM系统里见过一个“标签”字段，存的是“VIP,老客户,高消费”。查询“所有VIP客户”时，只能用 LIKE '%VIP%'，全表扫描，慢得要命。这就是违反1NF的典型恶果。

第二范式（2NF）：非主键字段必须完全依赖于主键

说白了，就是不能有“部分依赖”。比如订单明细表，主键是（订单ID, 产品ID）。如果这个表里还存了“客户姓名”，那就出问题了——客户姓名只依赖于订单ID，不依赖于产品ID。这会导致数据冗余和更新异常。

正确的做法是：把客户姓名放到客户表里，订单明细表只存订单ID和产品ID。

第三范式（3NF）：非主键字段不能传递依赖于主键

意思是，不能有“A依赖B，B依赖主键”这种传递关系。比如订单表里存了“客户ID”和“客户等级”。客户等级依赖于客户ID，而客户ID依赖于订单ID。这就产生了传递依赖。

正确的做法是：订单表只存客户ID，客户等级放到客户表里。需要时通过JOIN查询。

实战中的取舍——理论是死的，人是活的

你可能会问：那到底要不要严格遵守范式？我的答案是：看场景。

场景	建议	原因
OLTP（在线事务处理）	严格遵循3NF	保证数据一致性，避免更新异常
OLAP（在线分析处理）	适当反范式化	减少JOIN，提升查询性能
日志/历史数据	可以违反1NF	写入频繁，查询少，冗余可接受

举个例子。在CRM系统的客户详情页，需要展示客户的基本信息、最近订单、关联的销售记录。如果严格3NF，一次页面请求可能要关联5张表。我通常会设计一张“客户宽表”，把常用字段冗余进去，查询时一张表搞定。但写入时，要保证多表同步更新，这是代价。

好了，这一章就到这里。基础打牢了，后面咱们才能聊索引优化、分库分表这些硬核内容。下一章，我会带大家用实际案例，把今天讲的概念串起来，画一张完整的CRM系统ER图。