[!info] related notes

• 所属 MOC: 数据库 MOC
• 前置概念: [[z/database|数据库]], 数据库管理系统
• 建模概念: 一对多关系, 多对多关系与连接表, ER 模型, 数据库规范化
• 约束概念: 主键, 外键, 约束
• 并列资源: MySQL, PostgreSQL, SQLite
• 易混淆概念: 对象关系映射 ORM

关系型数据库

一句话定义

关系型数据库用表、行、列、键和约束表示结构化事实与事实之间的关系，并主要通过 SQL 定义、查询和修改这些数据。

核心模型

关系数据库不只是“把数据放进表格”，而是在数据库层明确：

Table       → 一类事实 / 实体集合
Row         → 一个具体事实
Column      → 事实的属性
Primary Key → 一行是谁
Foreign Key → 这一行引用谁
Constraint  → 什么状态合法

Schema 因而不仅描述“有哪些字段”，还定义持久化层允许出现哪些状态。

关系如何落到表里

一对多

User 1 ─── N Assessment

通常把 users.id 作为 assessments.user_id 外键放在“多”的一侧。

多对多

Student N ─── N Course

通常引入连接表：

Student 1 ─── N Enrollment N ─── 1 Course

关系本身的属性，如 Enrollment.grade，也应存放在连接表中。

为什么关系数据库强调约束

应用层可以做 Validation，但数据库仍应守住持久化不变量，例如：

• NOT NULL：值必须存在；
• UNIQUE：不能出现重复候选值；
• PRIMARY KEY：稳定标识一行；
• FOREIGN KEY：维持引用完整性；
• CHECK：值必须满足数据库可表达的条件。

这样即使某个服务代码出现缺陷、并发竞争或存在多个写入入口，数据库仍能拒绝部分非法状态。

查询关系

数据被规范化到不同表后，需要通过 SQL JOIN 在查询时重新组合，并可继续使用 GROUP BY 和 聚合函数 做统计。

规范化和 JOIN 是同一设计取舍的两面：写入时减少重复事实，读取时按需要组合事实。

它适合什么场景

• 数据结构和关系相对明确；
• 一致性和事务语义重要；
• 需要跨实体关联查询；
• 需要数据库层强约束；
• 业务事实需要长期、可靠地持久化。

边界与易混淆点

• 关系型数据库不等于“只能存完全固定结构”；PostgreSQL 等也支持 JSON、全文检索和扩展类型。
• SQLite、PostgreSQL、MySQL 都属于关系型数据库，区别主要在部署模型、功能与并发/运维边界，不是“新旧数据库”的关系。
• ORM 是应用层访问关系数据库的抽象，不是数据库本身，也不能替代 SQL、约束和事务知识。
• 表结构清晰不代表建模正确；仍要考虑依赖关系、基数、唯一性和查询模式。