跳到主要内容

为何选择 Prisma ORM？

在本页中，你将了解到 Prisma ORM 的动机，以及它与传统 ORM 和 SQL 查询构建器等其他数据库工具的比较。

使用关系型数据库是应用程序开发中的一个主要瓶颈。调试 SQL 查询或复杂的 ORM 对象常常耗费数小时的开发时间。

Prisma ORM 通过提供一个清晰且类型安全的 API 来提交数据库查询，该 API 返回普通 JavaScript 对象，从而使开发者更容易理解其数据库查询。

TLDR​

Prisma ORM 的主要目标是提高应用程序开发者在使用数据库时的生产力。以下是 Prisma ORM 实现这一目标的几个例子：

  • 以对象思维，而不是映射关系型数据
  • 以查询为中心，避免复杂的模型对象
  • 数据库和应用模型的单一真相来源
  • 健康的约束，防止常见的陷阱和反模式
  • 使正确的事情变得容易的抽象（“成功陷阱”）
  • 类型安全的数据库查询，可在编译时进行验证
  • 更少的样板代码，让开发者专注于应用程序的重要部分
  • 代码编辑器中的自动补全，无需查阅文档

本页的剩余部分将讨论 Prisma ORM 如何与现有数据库工具进行比较。

SQL、传统 ORM 和其他数据库工具的问题​

Node.js 和 TypeScript 生态系统中当前存在的数据库工具的主要问题是，它们需要在生产力和控制之间做出重大权衡。

Productivity vs Control in ORMs, SQL query builders, and SQL

原生 SQL：完全控制，低生产力​

使用原生 SQL（例如，使用原生的 pg 或 mysql Node.js 数据库驱动程序），你可以完全控制数据库操作。然而，生产力会受到影响，因为向数据库发送纯 SQL 字符串很麻烦，并且伴随着大量开销（手动连接处理、重复的样板代码等）。

这种方法的另一个主要问题是，你无法获得查询结果的任何类型安全。当然，你可以手动为结果添加类型，但这工作量巨大，并且每次更改数据库 schema 或查询以保持类型同步时都需要进行重大重构。

此外，以纯字符串形式提交 SQL 查询意味着你在编辑器中无法获得任何自动补全。

SQL 查询构建器：高控制，中等生产力​

一个常见的解决方案是使用 SQL 查询构建器（例如 knex.js），它在保持高控制水平的同时提供更好的生产力。这类工具提供了一个编程抽象来构建 SQL 查询。

SQL 查询构建器最大的缺点是应用程序开发者仍然需要以 SQL 的方式思考他们的数据。这将产生将关系型数据转换为对象的认知和实践成本。另一个问题是，如果你不清楚 SQL 查询中正在做什么，很容易弄巧成拙。

传统 ORM：更少控制，更高生产力​

传统 ORM 通过让你将应用程序模型定义为类来抽象化 SQL，这些类被映射到数据库中的表。

“对象关系映射器”（ORM）的存在是为了弥合程序员的朋友（对象）和数据库的基本单元（关系）之间的差距。这些不同模型的原因既有文化因素，也有功能因素：程序员喜欢对象是因为它们封装了运行程序中某个事物的状态。数据库喜欢关系是因为它们更适合整个数据集的约束和高效的访问模式。

《令人头疼的 Active Record 模式》，Cal Paterson (2020)

然后，你可以通过调用模型类的实例上的方法来读写数据。

这方便得多，并且更接近开发者思考数据时的心理模型。那么，问题出在哪里呢？

ORM 代表了一个泥潭，一开始进展顺利，随着时间的推移变得越来越复杂，不久之后就将用户困在一个没有明确界限、没有明确胜利条件、也没有明确退出策略的承诺中。

《计算机科学的越南》，Ted Neward (2006)

作为一名应用程序开发者，你对数据的心理模型是对象。另一方面，SQL 中数据的心理模型是表。

这两种不同数据表示之间的差异通常被称为对象关系阻抗不匹配。对象关系阻抗不匹配也是许多开发者不喜欢使用传统 ORM 的主要原因。

例如，考虑一下每种方法如何组织数据和处理关系：

  • 关系型数据库：数据通常是规范化的（扁平的），并使用外键跨实体链接。然后需要通过 JOIN 来体现实际关系。
  • 面向对象：对象可以是深度嵌套的结构，你可以通过使用点符号轻松遍历关系。

这暗示了传统 ORM 的一个主要陷阱：尽管它们让你看起来可以通过熟悉的点符号简单地遍历关系，但底层 ORM 生成的是 SQL JOIN，这开销巨大，并且可能大大减慢应用程序的速度（其中一个症状就是n+1 问题）。

总结：传统 ORM 的吸引力在于其前提是抽象化关系模型并完全以对象的角度思考数据。虽然前提很棒，但它基于关系型数据可以轻易映射到对象的错误假设，这导致了许多复杂性和陷阱。

应用程序开发者应该关心数据，而不是 SQL​

尽管 SQL 是在 20 世纪 70 年代(!)，它以令人印象深刻的方式经受住了时间的考验。然而，随着开发者工具的进步和现代化，值得思考 SQL 是否真的是应用程序开发者使用的最佳抽象。

毕竟，开发者应该只关心实现某个功能所需数据，而不是花费时间去弄清楚复杂的 SQL 查询或整理查询结果以满足他们的需求。

在应用程序开发中，还有另一个反对 SQL 的论点。如果你清楚自己在做什么，SQL 的强大功能可能是一件好事，但其复杂性也可能是一件坏事。有许多反模式和陷阱，即使是经验丰富的 SQL 用户也难以预测，这通常以牺牲性能和数小时的调试时间为代价。

开发者应该能够请求他们所需的数据，而不是担心他们的 SQL 查询中“做正确的事情”。他们应该使用一种能够为他们做出正确决定的抽象。这可能意味着这种抽象施加了一些“健康”的约束，防止开发者犯错。

Prisma ORM 提高开发者生产力​

Prisma ORM 的主要目标是提高应用程序开发者在使用数据库时的生产力。再次考虑生产力与控制之间的权衡，Prisma ORM 正好处于这个位置：

Prisma ORM makes developers productive