数据库完整性具体包括哪些方面？

为什么数据库完整性是每个项目都必须关注的痛点

在实际开发和运维过程中。常见的痛点包括：

• 业务报错频发，却找不到根源——往往是因为脏数据进入了库。怎么说呢，
• 数据迁移或版本升级后出现“主键冲突”“外键失效”。导致程序不可用，
• 审计和合规检查时发现大量不符合业务规则的数据，整改成本高昂。

这些问题的根本原因都是缺乏完整性约束。通过合理设计数据库完整性，可以在数据写入阶段拦截错误。显著降低后期排查和修复成本。

数据库完整性的主要组成

1. 实体完整性

实体完整性保证表中的每一行记录都有唯一且非空的标识符，即主键。从实现方式包括来看，

• 定义主键约束。
• 对组合主键使用多个列共同唯一标识。
• 避免使用可能重复或可为空的列作为主键。老实说，

2. 域完整性

域完整性限制列的数据类型、取值范围、格式等规则。防止非法值写入，再看例如，

• INT 列只能存整数。配合 CHECK 限制为正数。
• VARCHAR 配合正则表达式确保邮箱格式正确。
• Date 列使用 CHECK 限定合理时间范围。

3. 参照完整性

参照完整性确保表之间的关联关系有效，即外键必须引用存在的主键值。实现方式的观点是，

• FOREIGN KEY REFERENCES parent_table
• 设置级联操作（ON UPDATE CASCADE。ON DELETE RESTRICT) 以防止孤儿记录。
• 在删除/更新父表记录时自动检查子表约束，避免数据不一致。老实说，

4. 使用者自定义完整性

业务层面的特殊规则往往超出标准约束。需要自行定义：

• CUSTOM CHECK: 如 “订单金额必须大于等于运费”。
• 触发器: 在 INSERT/UPDATE 前后执行复杂校验或自动填充字段。
• S​tored Procedure / Function: 对跨表或跨行的业务逻辑进行统一验证。

5. 时间/历史完整性

*在需要追踪数据变化历史的程序中*，时间完整性通过时间戳或有效期字段保证同一实体在不同时间点的数据状态一致。例如的观点是，

• TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
• EFFECTIVE_FROM / EFFECTIVE_TO

如何落地实现这些约束——实战要点

A. 在模型设计阶段即加入约束

1. DML 前置校验：Mysql/PostgreSQL 等 DBMS 支持在建表语句中直接声明 COLUMN TYPE CHECK …说起来，,主键、唯一、外键等。话说回来，不要等到代码层面再做检查。
2. L​ayered Validation：E‑R 图 → DDL → ORM 映射层 → 应用层。都应保持约束的一致性，避免“代码里有校验但 DB 没有”。

B. 使用触发器补足 DBMS 不支持的复杂规则

- 例如：订单状态只能从 “待付款” 变为 “已付款”，不能直接跳到 “已完成”。可以写一个 BEFORE UPDATE 触发器检测状态转移合法性。

C. 定期审计与监控

- 利用程序视图检查是否遗漏关键约束。话说回来，- 设置审计日志，对外键删除、主键冲突等异常事件实时报警。

D. 测试驱动验证

- 编写单元测试或集成测试，用插入非法数据的方式验证所有约束是否生效。老实说，这样可以在 CI/CD 阶段捕获潜在的数据质量风险。

完整性的价值远超“额外工作”本身

通过实体、域、参照还有使用者自定义四大约束程序。可以在数据写入瞬间阻止错误产生,从而避免后期排查、修复还有合规审计带来的高昂成本。话说回来，将这些约束视为业务规则的一部分。而非可选功能，是提高程序可靠性和维护效率的关键一步。

立即行动建议清单

1. #1 检查现有表结构：P​​RAGMA table_info / INFORMATION_SCHEMA.COLUMNS 查看是否缺失主键、唯一索引或 CHECK 约束。
2. #2 为关键表添加主键/唯一约束：If missing,ALTER TABLE 添加并处理已有重复记录。
3. #3 为所有外键建立参照完整性：Add FOREIGN KEY 并根据业务选择级联策略。
4. #4 梳理业务规则并转化为 CHECK 或 Trigger：E.g.,“年龄> 0 且 ≤ 120”。
5. #5 建立每日/每周审计脚本监控异常插入日志，并配置告警。