服务端项目只要进入真实业务，就绕不开数据持久化。但“会连数据库”不等于“知道该怎么设计数据访问层”。这一篇会从数据库类型、访问方式和事务边界入手，帮助读者建立最基础的后端持久化认知。
SQL 和 NoSQL 为什么不是简单对立关系？
很多初学者第一次选数据库时，容易把问题理解成“到底谁更高级”。但更实际的判断方式应该是：你的数据关系、查询模式和一致性需求到底是什么。
关系型数据库通常更擅长：
- 结构清晰的数据模型；
- 复杂查询；
- 强一致性要求；
- 多实体关系处理。
而 NoSQL 往往更适合：
- 结构变化快；
- 某些读写模式非常特殊；
- 更强调灵活存储或特定访问模式。
也就是说，选择的重点不是跟风，而是让存储模型服务于业务问题。
ORM 和 Query Builder 各自解决什么问题？
Node 生态里最常见的几种数据访问方式，大致可以理解成：
- ORM：更高层抽象，强调模型和对象映射；
- Query Builder：更贴近查询过程，但比手写 SQL 更结构化；
- 原生 SQL：最直接也最灵活。
ORM 的优势通常是：
- 开发体验更统一；
- 模型和业务代码衔接更自然；
- 适合很多典型 CRUD 场景。
而 Query Builder 的优势在于：
- 对查询过程的掌控感更强；
- 比纯 ORM 更贴近真实查询；
- 在复杂查询场景下通常更灵活。
所以，关键不在于哪一个“更高级”，而是你的项目需要多少抽象、多少控制力。
仓储层为什么值得存在？
一旦服务端项目开始变大，数据库操作不应该直接散落在控制器和业务流程各处。仓储层的价值，就是把“数据如何被读取和写入”这件事单独聚合起来，让业务层更聚焦于规则和流程。
这不只是为了好看，而是为了：
- 更容易测试；
- 更容易替换实现；
- 更容易把数据库关注点和业务关注点分开。
事务为什么是业务一致性问题？
很多人第一次接触事务时，会把它理解成数据库小节里的某个高级用法。但从业务角度看，事务真正解决的是：一组本应一起成功或一起失败的操作，如何保持一致。
也就是说，事务边界本质上是业务边界。它在回答的是：
- 哪几步必须被视为一个整体；
- 一旦中间失败，该如何回滚；
- 什么情况下系统可以接受部分成功，什么情况下不行。
所以，事务从来不只是数据库语法问题，而是系统一致性设计的一部分。
总结
这一篇我们把 Node 服务端的数据持久化主线先梳理清楚了：SQL 和 NoSQL 是两类问题取向，ORM 和 Query Builder 是两种不同抽象层级，而仓储层与事务边界则帮助你把数据访问真正纳入工程结构和一致性思维中。
下一篇我们会继续进入业务系统里最常见的一条主线，也就是身份认证和权限控制。