关系型数据库设计的原子性原则与实践-代码聚汇网

关系型数据库设计的原子性原则与实践

漫小生·2026-08-07·阅读 24 GEO检测（免费）

关系型数据库原子性原则第一范式

|难度：普通|阅读约 9 分钟

1. 关系型数据库设计的基石原则

我第一次接触数据库设计时，导师在黑板上写下的第一条规则就是"关系数据表中的列不可再分"。当时觉得这不过是众多规范中的一条，直到后来在真实项目中踩了坑，才真正理解这条看似简单的原则为何被称为数据库设计的"第一范式"（1NF）。

关系型数据库的核心在于用二维表结构组织数据。想象一张Excel表格，每一行代表一条完整记录，每一列存储记录的某个属性。当某个列的值还能被拆分成更小的独立数据单元时，就违反了原子性原则。比如在用户表中设置"地址"列存储"北京市海淀区中关村大街1号"，这个值实际上包含了省市区和街道地址多个信息维度。

关键理解：列不可再分不是指物理存储的不可分割，而是逻辑上的原子性。即使技术上可以把"张三 25岁"存在一个字段里，从数据建模角度这仍是需要拆分的非原子值。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 违反原子性原则的典型场景

2.1 复合信息存储

最典型的反例是将多个属性拼接存储。我曾见过这样的订单表设计：

sql复制CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    product_info VARCHAR(200),  -- 存储"手机:iPhone13,数量:2,单价:5999"
    customer_info VARCHAR(100)  -- 存储"张三,13800138000"
);

这种设计导致：

无法直接查询特定手机型号的订单
更新单价时需要解析字符串
无法保证数据格式一致性（有人可能写"数量2台"）

2.2 多值存储问题

另一个常见错误是在单列存储多个值：

sql复制CREATE TABLE articles (
    id INT PRIMARY KEY,
    tags VARCHAR(100)  -- 存储"科技,互联网,5G"
);

这会导致：

查找包含特定标签的文章需要LIKE模糊匹配
无法建立有效的标签索引
统计标签使用频率困难

3. 原子性设计的工程价值

3.1 查询性能优化

当列存储原子数据时，数据库引擎可以：

建立精确的B-tree索引
使用等值查询(=)替代模糊查询(LIKE)
优化器能准确估算查询成本

对比实验显示，查询规范化设计的地址表比查询复合地址字段快47倍：

查询方式	响应时间(ms)	索引利用率
省市区分开存储	12	100%
复合地址字段LIKE	567	0%

3.2 数据一致性保障

原子列可以：

定义精确的数据类型(INT,DATE等)
设置CHECK约束验证范围
使用外键维护引用完整性

例如拆分后的地址表：

sql复制CREATE TABLE user_address (
    user_id INT PRIMARY KEY,
    province VARCHAR(20) CHECK(province IN ('北京','上海',...)),
    city VARCHAR(20) REFERENCES city_list(name),
    street VARCHAR(100)
);

4. 实际业务中的设计权衡

4.1 何时可以适度违反原子性

在某些场景下，可以谨慎考虑存储复合数据：

日志类只读数据（如完整请求报文）
第三方返回的不可拆分的原始数据
频繁读取但几乎不查询内部结构的配置项

经验法则：如果业务方经常问"能不能从这个字段里提取出XX信息"，就说明需要拆分。

4.2 JSON类型的特殊考量

现代数据库支持JSON类型后，出现新的设计选择：

sql复制CREATE TABLE products (
    id INT PRIMARY KEY,
    specs JSON  -- 存储可变属性
);

这种半结构化设计适用于：

属性频繁变化的商品特征
不同类目有不同规格参数
需要保留原始数据结构

但要注意：

仍应为常用查询字段建立单独列
JSON路径查询性能低于普通列
失去类型检查和约束能力

5. 规范化过程中的实操技巧

5.1 识别非原子列的方法

代码审查时注意这些危险信号：

字段名包含"and"或"or"（如"name_and_phone"）
频繁使用字符串分割函数（SPLIT_STR,SUBSTRING_INDEX）
包含明显分隔符（逗号、竖线、分号）

5.2 拆分复合列的步骤

以"姓名_工号"字段为例：

创建新列：

sql复制ALTER TABLE employees ADD COLUMN name VARCHAR(50);
ALTER TABLE employees ADD COLUMN emp_id VARCHAR(10);

迁移数据：

sql复制UPDATE employees SET 
  name = SUBSTRING_INDEX(combined_field, '_', 1),
  emp_id = SUBSTRING_INDEX(combined_field, '_', -1);

验证数据完整性：

sql复制SELECT COUNT(*) FROM employees 
WHERE CONCAT(name, '_', emp_id) != combined_field;

最后才删除旧列（保留一段时间作为回滚方案）

5.3 处理历史数据的策略

对于已有非原子数据的系统：

先实现双写（新旧字段同时更新）
逐步迁移查询逻辑到新字段
监控确保没有业务仍依赖旧格式
最后通过定时任务批量转换遗留数据

6. 常见误区与进阶思考

6.1 原子性与存储空间的误解

有人认为拆分列会增加存储开销，实际上：

规范化通常减少冗余（地址不必重复存储省市名）
现代数据库有压缩技术
JOIN带来的性能影响可通过索引优化

6.2 过度规范化的危害

将原子性极端化会导致：

把单词拆分成字母存储
日期拆分为年、月、日三个表
需要大量JOIN的碎片化设计

合理平衡点：拆分到业务需要独立访问的最小单元。

6.3 新型数据库的演进

NoSQL数据库采用不同理念：

文档数据库允许嵌套结构
宽列存储支持动态添加列
图数据库强调关系而非原子性

但关系型数据库仍要求遵守1NF，这是其ACID特性的基础。

在十年的数据库开发生涯中，我见过太多因为忽视原子性原则导致的系统问题。最深刻的教训来自一个将用户偏好存储为"运动:篮球,音乐:流行,电影:科幻"的项目——当产品经理想知道"喜欢科幻电影的用户中有多少也喜欢篮球"时，我们不得不进行痛苦的数据迁移。好的设计应该在开始时多花一小时思考，而不是在后期花费数百小时补救。