为何要用 Prisma？

这是一篇译文，原文在此：www.prisma.io/docs/unders…

概述

这篇文章将阐述咱们开发 Prisma 的动机，以及与其余数据库工具（如 ORM 和 SQL 构造器）相比 Prisma 有什么优势。

Web 应用的开发过程当中，须要花费大量时间与关系型数据库打交道，你可能须要花费数小时来调试 SQL 查询语句或者复杂的 ORM 对象模型。

Prisma 则提供一套简洁的 API，使你更加方便地操做数据库和理解查询语句。Prisma 的 API 是类型安全的，返回的数据是普通的 JS 对象（plain old JavaScript objects）。

SQL、ORM等数据库工具的问题

现存于 Node.js 和 TypeScript 生态环境中的数据库工具的主要问题是：没法很好的权衡生产力和控制力。

手写 SQL：控制力极强，生产力弱

本身手写 SQL（好比使用 pg 和 mysql 这样的 Node.js 数据库驱动）固然能够彻底控制数据库操做，可是，生产力却不高，并且会遇到不少细碎的事情（如手动处理连接、操做模板）。这种方式的另外一个问题在于你获取的查询结果时不是类型安全的。你可能会手动书写这些查询结果的类型，但这会花费大量的时间；另外，若是你对数据库进行了改动，你的类型文件也须要保持一致才行，这也会花费大量时间。

此外，手动构造 SQL 字符串的时候，编辑器无法给你任何提示（只能提示一些 SQL 关键字），效率极差。

SQL 构造器：控制力强，生产力通常

有很多人用的解决方案是使用 SQL 构造器（如 knext.js）以提升生产力。这种工具为构建 SQL 语句提供了封装层次较高的 API。但最大的问题在于这种工具须要开发者从 SQL 的角度来对待数据，但应用数据每每是关系型的对象，这就会致使了数据在认知层面与实际层面的差别。开发者不得不常常切换思惟模型才能写好 SQL 语句。

另一个问题是，若是开发者对 SQL 的掌握若是不够好，常常会搬起石头砸本身的脚。

ORM：控制力弱，生产力不错

ORM 可让开发者将全部数据定义为 class，一个 class 就是一个数据表，开发者不须要对 SQL 有那么深的理解了。

你能够经过 class 的方法来对数据库进行读写，很是方便，并且也很是接近开发者的心智模型。

那么缺点是什么呢？

ORM 像一个泥沼，一开始仍是平地，可是随着时间的推移，它愈来愈复杂，不久以后就将其用户陷于一个没有明确分界点、没有明确获胜条件、也没有明确退出策略的承诺中——The Vietnam of Computer Science

开发者将数据理解为一个一个的对象集合，但实际上这些数据是一个一个的表。

这种认知上的差别会致使「对象关系阻抗不匹配（Object-relational impedance mismatch）」，这种不匹配正是不少开发者不喜欢传统 ORM 的缘由。

举例来讲，两种认知到对象关系的处理是不同的：

• 关系型数据库认为数据都是平的（flat），使用外键来连接不一样的实体，若是想要体现两个实体的关系，就须要用 JOIN 语句。
• 面向对象认为对象是能够嵌套的（nested），经过点符合就能访问到与实体相连的另外一个实体。

这个例子揭露了 ORM 的一个大陷阱：使用 ORM 表面上能够经过点符合来访问另外一个实体，可是私底下却会构造 SQL JOIN 语句，这些 JOIN 是有性能陷阱的，极可能把你的应用拖得很慢，好比著名的 n+1 问题。

总之，ORM的优势是抽象出关系模型并仅根据对象来操做数据。可是问题在于，关系型数据表并不能轻松地映射到对象，这会带来不少复杂性，从而引起陷阱。

开发者应该关心数据，而不是 SQL

1970年代出生的 SQL 是一门久经考验的语言，但随着开发工具的发展，咱们不由要问，SQL 真的是数据的最好抽象方式吗？

毕竟，开发者实现需求时，只须要关心其涉及到的数据，而不是花时间弄清复杂的 SQL 查询，还要对查询结果的结构进行调整，才能去作需求。

还有一个对 SQL 的争议，若是你精通 SQL，那么 SQL 是一个强大的工具；可是 SQL 的学习曲线是很陡峭的，不少经验丰富的 SQL 使用者都会不当心用错 SQL 踩到坑，形成应用的性能损失，还要花大量的时间来调试。

开发者须要一个工具来获取他/她须要的数据，同时不用担忧本身用错了 SQL。他/她们须要一个工具帮他们作出对的选择，这意味着须要有一个「健康的约束」来防止出错（译者注：就好像人类为了健康，要少吃油腻食品同样，少吃油腻食品就是健康的约束）。

Prisma 让开发者更有生产力

Prisma 的主要目标就是让开发者在处理数据库是更具生产力，为了达到这个目的，Prisma 作出了如下努力：

• 用对象来思考，而不是在大脑中映射关系型数据库
• 查询不是类，以免复杂的数据模型
• 单一真理来源，数据库和数据模型来自同一个地方
• 健康的约束，用来防止常见的陷阱和反模式
• 使作正确的事情变得容易（“成功之道”）
• 查询结果类型安全
• 少用模板，这样开发者能够关注于业务
• 编辑器自动补全

再次回到以前的那张图，Prisma 在图中的位置是这样的

控制力高于 SQL 构造器，低于手写 SQL；

但生产力最高！