当你已经有一个意向的时候，后续的所有选择都会围绕这个意向进行。好的坏的都是它与生俱来的光环一样，心中总充满“他不一样”的想法🥵无论好坏总是被深深吸引
这几天在搞一个项目，在 ORM 选型时， 在 Prisma 和 drizzle 之间犹豫了好久，最后选择了 drizzle。
明明 Prisma 已经是一个很成熟的框架了，并且背后有一家成熟的商业公司来支撑它。为什么我选择了一个连 1.0 版本都没发布的 drizzle 呢？
原因大致如下：
- 我需要 ORM 能和前端共享数据模型的类型
- 我想要一个轻量一点的 ORM
- 我希望能够更灵活地构建查询
- 如果能顺便在这过程中学一点 SQL 就更好了
我们来分析一下。如果要做数据类型的分享，将数据模型抽离到一个单独的包中，我们就可以比较轻松的实现共享数据库模型的类型了。 相对于 Prisma 来说 drizzle 的类型定义是 TypeScript 实现的，前端可以直接使用它！ 并且它有官方集成的 zod 适配器，可以很方便地将数据模型转换为 zod 的验证模式。
对于易用性来说，Prisma 无疑是更好的选择，它提供了一套抽象的写法，让我们在不熟悉数据库操作时也能做一些很复杂的查询。 drizzle 则更多的是对 SQL 语句的一层抽象，很轻量级。一些复杂的查询需要有一些数据库使用经验才好实现。 相对于书写时的层层嵌套语法来说，我更喜欢 drizzle 这种类似 SQL 的写法，很简洁。 但是 Prisma 很易用😅
对于数据模型的定义，Prisma 也有它的优势，Prisma 有自己的 DSL 来定义数据模型，并且可以通过 prisma migrate 来生成和更新数据库结构。 drizzle 则是通过 TypeScript 的类型定义来描述数据模型，并且需要手动编写迁移脚本。而且需要自己管理外键。这 一方面 Prisma 也有很大的优势。但是如果你更喜欢 SQL 的话，那么选择 drizzle 会更合适一些。
就像上面所说的，我希望我在写项目时可以顺便熟悉一下 SQL 的各种操作，那么选择 drizzle 就更加合适了。 而且在一些复杂的查询中我们可以直接在 drizzle 中写 SQL 语句，当然 Prisma 也支持就是了。
虽然我对 SQL 并不是很了解，但不妨碍我“叶公好龙”似的喜欢它。我总是幻想着某一天我在写其他语言的数据库查询时，可以很方便的将我在 Nodejs 中学到的 SQL 知识迁移过去。 但是目前看我太喜欢 JavaScript 生态了，可能对于写其他语言的机会没有很多🤣
说了这么多，好像并没有提到他两连接数据库时查询性能的区别，这方面 drizzle 因为它更轻量的封装，对于 Prisma 这种需要更多抽象的 ORM 来说，性能上的优势就很明显了。