使用 prisma 操作数据库

fjywan • 2023-01-02 • 云技术社区 • 280 阅读

一个几乎不需要看文档就能使用的 ORM —— prisma。

背景

ORM：Object-relational mapping，是把对象和关系型数据库建立映射的过程。实际应用开发中，基本都会引入 ORM 来辅助操作数据库，通常被提及的好处，例如：

可移植性，方便切换数据库；
比直接写 SQL 效率高，方便多表联查等；
可维护性高，和业务代码语言一致 ...

和所有的技术选型一样，没有一种尺寸，适合所有的情况，ORM 也是如此。

下面看看操作数据库有哪些途经，以及利弊。

操作数据库的途经

High level: ORM

使用 ORM 的好处，前面已经提到。实际应用开发中，不是所有的好处都成立，比如可移植性，目前还没有中途换数据库的情况，换数据库基本表明前期的方案设计有致命缺陷。

而且，如果下面的原因，更应该慎重选择 ORM：

避免学习背后的 SQL

这无疑加大应用开发时的挫败感。每个报错，都会逼迫深入 SQL，甚至储存原理，而且你总会碰到报错。

此外，关于特定 ORM 的使用经验，很难跨语言迁移，甚至跨库迁移都不容易，想象下 sequlize 和 typeORM。

下次再想走捷径的时候，屏息一分钟，想象站在陡峭的高山下：面前一个艰险的云梯，直上直下；一个盘山公路，平坦宽阔。选择走哪个？

最难的路 —— 直上直下的云梯，才是路径最短的路。

表达力有限

这个取决于具体使用的 ORM，比如 where 中存在子查询的场景，一般写法比较繁琐。

如果因为上面或其他原因，需要剥开 ORM 的抽象，继续下探，Query builder 是一个不错的过渡。

Middle level: Query builder

比如 Node 中流行的 Knex.js。

激进派可能直接从 ORM 跳到了 raw sql，最后不过是又积累了一遍自己的 query builder —— 重复造轮子。

日常应用开发中，高频场景模式固定，存在大量 sql 片段在不同查询中重复。query builder 就是消除这种重复的辅助函数。

Low level: Database driver

这一层，也称为 raw sql。不管是因为 ORM 表现力不够，还是需要某种更底层的特性（直接控制connection pool?)，这时，node-mysql2 是个不错的选择。

不过天平的另一端：缓存、防注入、执行效率、唯一索引校验等都需要自己额外关注。

另外经常 explain sql，既然都到这一层了，自己写的 sql 执行效率还没 ORM 自动生成的高，就说不过去了。

Node ORM prisma

在熟悉了 MYSQL 工作原理、SQL 语法后，日常应用开发中强烈推荐 prisma，能极大消除重复。

基本用法

假设链接到一个已有的数据库。

安装，并初始化

npm install prisma -S

// 生成 schema.prisma 和 .env
npx prisma init 

// 根据 .env 配置的数据库 URI，链接数据库、更新 schema
npx prisma db pull
// 通过 schema 生成桩代码和类型
npx prisma generate

应用中实例化一个 client

import { PrismaClient } from '@prisma/client';
export const prisma = new PrismaClient({
  // 可以根据需要开启不同等级的 log
  // log: ['query', 'info', 'warn', 'error'],
});

3.. service 中使用

在输入 prisma 对象后，立即提示所有可选的表名，不要惊讶，当继续输入任何一个方法后，比如 upsert，会看到下面的用法提示：