一个几乎不需要看文档就能使用的 ORM —— prisma。
ORM:Object-relational mapping,是把对象和关系型数据库建立映射的过程。 实际应用开发中,基本都会引入 ORM 来辅助操作数据库,通常被提及的好处,例如:
和所有的技术选型一样,没有一种尺寸,适合所有的情况,ORM 也是如此。
下面看看操作数据库有哪些途经,以及利弊。
使用 ORM 的好处,前面已经提到。实际应用开发中,不是所有的好处都成立,比如可移植性,目前还没有中途换数据库的情况,换数据库基本表明前期的方案设计有致命缺陷。
而且,如果下面的原因,更应该慎重选择 ORM:
这无疑加大应用开发时的挫败感。每个报错,都会逼迫深入 SQL,甚至储存原理,而且你总会碰到报错。
此外,关于特定 ORM 的使用经验,很难跨语言迁移,甚至跨库迁移都不容易,想象下 sequlize 和 typeORM。
下次再想走捷径的时候,屏息一分钟,想象站在陡峭的高山下: 面前一个艰险的云梯,直上直下;一个盘山公路,平坦宽阔。选择走哪个?
最难的路 —— 直上直下的云梯,才是路径最短的路。
这个取决于具体使用的 ORM,比如 where 中存在子查询的场景,一般写法比较繁琐。
如果因为上面或其他原因,需要剥开 ORM 的抽象,继续下探,Query builder 是一个不错的过渡。
比如 Node 中流行的 Knex.js。
激进派可能直接从 ORM 跳到了 raw sql,最后不过是又积累了一遍自己的 query builder —— 重复造轮子。
日常应用开发中,高频场景模式固定,存在大量 sql 片段在不同查询中重复。query builder 就是消除这种重复的辅助函数。
这一层,也称为 raw sql。 不管是因为 ORM 表现力不够,还是需要某种更底层的特性(直接控制connection pool?),这时,node-mysql2 是个不错的选择。
不过天平的另一端:缓存、防注入、执行效率、唯一索引校验等都需要自己额外关注。
另外经常 explain sql,既然都到这一层了,自己写的 sql 执行效率还没 ORM 自动生成的高,就说不过去了。
在熟悉了 MYSQL 工作原理、SQL 语法后,日常应用开发中强烈推荐 prisma,能极大消除重复。
假设链接到一个已有的数据库。
npm install prisma -S
// 生成 schema.prisma 和 .env
npx prisma init
// 根据 .env 配置的数据库 URI,链接数据库、更新 schema
npx prisma db pull
// 通过 schema 生成桩代码和类型
npx prisma generate
import { PrismaClient } from '@prisma/client';
export const prisma = new PrismaClient({
// 可以根据需要开启不同等级的 log
// log: ['query', 'info', 'warn', 'error'],
});
3.. service 中使用
在输入 prisma 对象后,立即提示所有可选的表名,不要惊讶,当继续输入任何一个方法后,比如 upsert,会看到下面的用法提示:
直接弹出了示例,甚至注释都是专属!
这就是使用代码生成方案的 prisma 相较于 sequelize 等的优势之处。
更重要的,获得这一切好处的成本几乎为 0 —— 数据库是唯一的数据源,自动化的流向了代码,什么也不需要做。
正如在根本提效途径中提到,工具的价值之一:自动化已有信息的传递。
prisma 通过生成查询桩代码/类型,自动化了数据库表信息到应用的传递。 而其他 Node ORM 库,普遍只做到了为 SQL 查询换一个写法:拿应用的语言来写。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。