数据库基础（Prisma/Drizzle）
前端工程师为什么越来越需要懂数据库
以前很多前端工作，和数据库之间隔着很长一段距离。
现在这条距离明显缩短了。
原因并不神秘：
- Next.js、Nuxt、SvelteKit 这类全栈框架更普遍
- BFF、server action、route handler 让前端更常碰到后端边界
- 小团队里，一个人往往既要做页面，也要接数据层
- edge、serverless、SQLite、serverless Postgres 让数据接入门槛下降
这并不意味着前端都要变 DBA。
但至少要理解：
- 数据是怎么组织的
- 查询成本从哪里来
- schema 变更怎么管理
- ORM 在帮你省什么，又遮住了什么
先把 ORM 讲清楚
ORM 可以简单理解成：
在应用代码和数据库之间，提供一层更可编程的查询与建模接口。
它的价值通常在于：
- 减少重复 SQL 拼写
- 让类型和 schema 更靠近
- 降低常见 CRUD 的心智成本
- 把迁移、生成、关系建模纳入同一套工具链
但它也不是白送的。
ORM 往往会带来：
- 抽象层
- 学习成本
- 某些性能细节被遮住
- 团队容易对 SQL 本身失去感觉
所以真正成熟的姿势不是“用不用 ORM”。
而是“理解 ORM 帮你做了什么，没帮你做什么”。
关系型数据库最少要懂哪些概念
如果你只写前端页面，这些词可能看起来有点后端。
但一旦你开始碰数据层，它们就是基础语境。
表
数据的结构化存储单位。
主键
唯一标识一条记录。
外键
表达表和表之间的关系。
索引
加速查询的数据结构。
它不是免费午餐。
写入和维护也有成本。
事务
一组操作要么都成功，要么都回滚。
迁移
把数据库结构变化做成可执行、可追踪的版本历史。
这些概念理解不到位，后面用任何 ORM 都会显得飘。
为什么 SQL 直觉仍然重要
即使你用了 ORM，也不要把 SQL 当成“底层黑盒”。
原因很简单：
数据库性能问题、关系设计问题、查询结果错位问题，最后都离不开数据模型和查询逻辑本身。
你不一定要手写很多复杂 SQL。
但至少要能判断：
- 这个查询是不是在做多余 join
- 这个字段要不要加索引
- 这次 schema 改动会不会影响已有数据
- 这个 N+1 是不是 ORM 抽象带来的
Prisma 和 Drizzle 为什么经常被放在一起比较
因为它们都处在现代 TypeScript 生态里。
但它们的气质并不一样。
Prisma 的倾向
Prisma 更强调：
- schema-first
- 统一工具链
- 自动生成 client
- 对团队协作友好的工作流
Prisma 官方文档现在也明确把自己和 Drizzle 放在一起比较，并强调：
- schema 可读性
- 类型安全
- migrate 工作流
- 团队可协作性
这很符合 Prisma 的整体定位。
Drizzle 的倾向
Drizzle 更强调：
- SQL-first 或至少更贴近 SQL
- TypeScript 原生表达
- 运行时代价更轻
- 对 edge / serverless 更友好
它并不是“更高级的 Prisma”。
也不是“功能更少的 Prisma”。
它只是做了不同权衡。
Prisma 最适合什么样的团队
通常比较适合这些情况：
- 团队里不是每个人都熟 SQL
- 希望数据模型表达更集中
- 想要较完整的 migration 和 client 工作流
- 希望 code review 时 schema 变更更容易读
Prisma 的优势常常不是某一条 query 更短。
而是整个数据层体验更统一。
Drizzle 最适合什么样的团队
通常比较适合这些情况：
- 团队接受甚至偏好更接近 SQL 的表达
- 更在意运行时轻量和部署灵活性
- edge / serverless 场景较多
- 希望 schema 定义、查询和 TypeScript 更自然地融在一起
Drizzle 的好处在于它不会把 SQL 感过度包起来。
这对很多有数据库意识的工程师来说是优点。
Prisma 的长处和边界
长处包括：
- 上手相对快
- schema 可读性强
- 生成 client 后消费体验一致
- migration 工具链成熟
- 对不擅长 SQL 的团队更友好
边界则包括：
- 抽象层更重
- 某些部署环境下运行时约束更多
- 团队如果完全不理解底层 SQL，后面仍然会踩坑
Drizzle 的长处和边界
长处包括：
- 更轻量
- 更贴近 SQL 语义
- 类型和 schema 紧密结合
- 在 edge 场景里常常更顺手
边界则包括：
- 对 SQL 直觉要求更高
- 团队如果没有基本数据建模能力，容易把类型安全误当成数据库设计能力
Migration 为什么是全栈工程里最容易被低估的一环
很多人第一次接数据库，关注的是“怎么查数据”。
真实系统里，schema 如何变化往往更关键。
因为你很快会遇到：
- 新增字段
- 改字段约束
- 改索引
- 拆表或合表
- 数据回填
这时 migration 就不是附属脚本。
它是生产变更的一部分。
成熟团队会非常认真地对待：
- migration 是否可追踪
- 是否能回滚
- 是否会锁表
- 是否需要分阶段发布
“先改 schema 再发代码”还是“先发代码再改 schema”
这类问题没有统一答案。
但成熟的判断一定会考虑兼容窗口。
例如一个常见稳妥模式是：
- 先加新字段，不删旧字段
- 让新旧代码能短暂共存
- 完成回填和流量切换后，再清理旧结构
数据库迁移最怕“一步到位”的浪漫。
现实里，可逆、可观察、可阶段化通常更重要。
事务为什么值得前端工程师理解
因为一旦你开始碰到：
- 创建订单并扣库存
- 提交表单并写多张表
- 写入业务数据同时记录审计日志
你就会遇到“部分成功、部分失败怎么办”的问题。
事务的价值就在这里。
它保护的是操作组的一致性。
即使你最终不直接写事务代码，也应该知道：
什么时候需要它，什么时候不能假装没有它。
Edge 和数据库为什么是一个特殊组合
这几年 edge 运行时很热。
但一旦连接数据库，你就会立刻碰到一些现实约束：
- 连接数
- 冷启动
- 连接池
- 地域延迟
- 驱动兼容性
这也是为什么“edge 友好”不是一句口号。
它需要具体看：
- 运行时支持什么
- 数据库接入方式是什么
- ORM 的运行时模型是否适配
在这件事上，Drizzle 往往更容易进入讨论，因为它更轻、更靠近 SQL 和驱动层。
而 Prisma 也在通过 Prisma Postgres、Accelerate 等能力回应这些场景。
“类型安全”为什么不等于“数据库设计正确”
这是非常值得单独强调的一点。
TypeScript 类型再强，也不能自动替你解决：
- 关系设计是否合理
- 索引是否合适
- 查询是否高效
- 事务边界是否正确
类型安全解决的是：
- 调用接口时少犯某些错误
- 字段变更更快暴露
- 代码消费体验更稳定
它不能替代数据建模本身。
前端工程师切入数据库时，最容易踩的坑
1. 只会增删改查，不看查询成本
写得出来，不代表跑得稳。
2. 过度相信 ORM 抽象
以为 ORM 帮你包起来了，底层问题就不存在了。
3. 不重视 migration
把 schema 变更当成开发阶段的小事。
4. 不理解连接与运行时约束
尤其在 serverless 和 edge 场景里，这会很快出问题。
中国互联网语境里的典型情况
很多国内团队的现实是：
- 业务系统复杂
- 数据结构变化快
- 新老系统并存
- 一部分团队前后端边界仍较清
- 另一部分团队已经在做 BFF 和全栈页面
这会让数据库认知越来越成为前端进阶项。
尤其当你做的是：
- 中后台
- 内容平台
- 电商链路
- 复杂表单流
数据模型理解会直接影响页面实现质量。
海外产品语境里，为什么 SQLite / serverless Postgres / edge data 更热
在很多海外生态里，开发者更早接受：
- 本地优先开发体验
- 平台化数据库服务
- 边缘部署配套的数据层
这会让 Drizzle、Turso、Neon 这类组合更常进入前端工程师视野。
但无论技术栈怎么换，底层判断仍然没变：
数据模型、迁移、安全性和查询成本都不能省略。
这类主题为什么很适合表达训练
因为它很容易被讲成：
- Prisma 简单，Drizzle 轻量
这只是第一层。
更像 senior 的讲法会继续说明：
- 它们分别在帮团队解决什么问题
- 为什么 SQL 直觉仍然重要
- migration 为什么比 CRUD 更值得警惕
- edge 场景为什么会改变 ORM 取舍
建议实践
实践 1：给一个小项目建完整 migration 流
练什么：
把 schema 变更当成真实发布的一部分。
最小交付物：
一个包含两到三次 schema 演进的 demo 项目。
验收标准：
- 每次变更都有 migration
- 新旧数据都能平稳过渡
常见误区：
- 直接改现有表结构，不留下迁移历史
实践 2：同一份 schema 分别用 Prisma 和 Drizzle 建模
练什么：
直观看两种工具链在团队体验上的差异。
最小交付物：
两个最小示例项目。
验收标准：
- 能说明各自优势和代价
- 能指出哪种更适合你的团队背景
常见误区：
- 只比较 API 手感，不比较 migration 和部署约束
实践 3：做一次索引和查询观察
练什么：
建立 SQL 与 ORM 之外的性能直觉。
最小交付物：
一个带索引前后对照的查询实验。
验收标准：
- 能观察查询时间或执行计划变化
- 能说明索引带来的收益和代价
常见误区：
- 只记住“索引更快”，不理解写入和维护成本