1

试试 kysely ，sql 的写法。或者用更火但 dx 差一些的 drizzle orm

2

😂你还真别说，迷信 prisma 的人多的一腿

3

我是从 typeorm 转到 prisma 的，prisma 确实有不少痛点，时区，联表查嵌套层级深什么的，但感觉开发体验上，prisma 还是要好一点

4

同样 delete 一个不存在的数据也会报错，官方解决方案说是用 executeRaw..

5

还好我是守旧派 一直用 sequelize

7

drizzle 比较好

8

也借地方顺便也让大家避坑一个 ORM：千万不要用 drizzle ，千万不要用 drizzle ，千万不要用 drizzle

9

drizzle

11

13

@asen001 真用了那就用嘛，也不是不能用，反正之前写 drizzle 我是真的火大
官方文档写得一塌糊涂，看起来很正规但有用的信息基本没多少
schema 一堆特性不支持，连最基本的 index desc asc, union index 都不支。到最后不光要写 schema 还要自己去写额外的 migration sql
类型检查基于 schema 定义，如果我 select 的字段里掺杂了动态生成自动的内容（比如 COUNT(*)之类）的话，过类型检查能折腾死人
执行 raw sql 并且获取到返回值而且要过类型检查比登天都难
等等等等，反正下次项目里谁跟我说用 drizzle 我跟谁急

14

knex 应该是用的最舒服的了，虽然只是一个 builder

16

目前应该是在 typeorm 中暂时不打算出去了。
prisma 在构建和打包时也会有很多问题。不设置 binary 的话会直接多 30M+的大小。很离谱。
然后里面还有一个奇怪的地方，当前 prisma 已经让用自定义 output 路径去做 client 的引入。
但是底层似乎有依赖了 prisma ，这个里面有个 public 文件夹，里面全是一些文档还是啥的。也是三十多 M.

17

18

在用 drizzle ，感觉很爽，可以写类似 sql 的语法，复杂查询很方便

20

我就觉得用 Prisma 能省点事，不用写一堆像 TypeOrm 中那样的实体对象，写很多注解

22

typescript 挺好的，不知道为什么 prisma 要发明新的格式

23

@BeautifulSoap
1. 文档的问题确实存在，过于简略，需要自己摸索
2.这些都支持啊，我一看还以为这是以前旧帖子呢。drizzle 基本就是把 ts 翻译成 sql ，这种一个关键字就解决的问题怎么会不支持。没有听说过 union index ，你是指复合索引吗，也支持的啊。union 操作倒是不支持是由于类型推断困难，不重视类型安全的可能会支持。
3. 类型检查当然要基于 schema 定义了，要不咋办？ count （*）可以使用 sql<number>标注类型
4. 同上，你不给类型标注，数据库返回的是 text ，不得按类型 parse 吗。

24

@cutchop 跟 drizzle 比起来 prisma 的 schema 确实简单好懂，我一个简单项目 drizzle schema 都快 1000 行了，除了我自己没人能看懂，估计也没人有耐心看完，幸好有 visualizer 。

27

用不上那些高大上的 orm 功能，转到了 postgres.is
楼上推荐的 Kysely ，感觉比较像 gorm ，有空试试

28

@rocmax
2. 你自己试试看 mysql 的 schema 里能不能指定 asc 或者 desc 的 index 吧。postgresql 可以，但是 mysql 不行的。并且 mysql 的复合索引文档里根本找不到怎么用
4. 这个你自己亲自写一下就知道了。就最简单的用 drizzle 执行 mysql 的 `show tables` 然后解析出所有表格。保证你一写一个不吱声。官方文档里只写了怎么执行 raw sql 但对怎么获取到 raw sql 的返回值只字不提。最后花了 N 久时间才找到解决办法

31

现在在用 drizzle ，但是感觉维护者对 mysql 相关的特性不太重视 ...

32

正在用 prisma 看了这帖子怕了，typeorm 简单试过一下，看到生成的 SQL 之后果断放弃，现在我对 JS 写 CRUD 一点兴趣都没了

33

三天时间不算浪费，至少你知道了不适合你现在这个项目。

34

@justdoit123 #17
我的做法是新建一个 class 来继承 prisma 对应的实体 class ，在新建的自有 class 的基础上去做各种字段装饰、处理操作

35

@Hanggi 我确实有可能没有完全理解 prisma 的设计思想。但在业务侧开发中我提到的那些问题，确实是实打实的极大的降低了开发效率和提高了心智负担。如果所有业务都是 CRUD ，prisma 的设计似乎也完全不考虑要实际开发的便利性。最简单的就是 update,delete 没有的数据会直接 Error ，这就引出了多一层 db 和 prisma 的心智负担。这种负担或者说设计让业务侧失去了便利性； model 的 relations 在实际开发中，尤其是 query 场景就几乎不可能把关系定义的完，也不可能依赖这种形式去定义。

38

39

不是很喜欢他又自己引入一套 schema 语言 所以尝试了一次就丢弃了。

40

@BeautifulSoap 这是两个事情，上面那个 sql<T>的类型标注是给 ts 侧看的不负责处理数据，你要根据实际返回的数据格式来标注给 ts ，数据本身是不用处理的。
下面那个用了 cast 所以没办法推断类型，应该在后面加一个 map With 做处理。
playground 没有 MySQL ，我有空搭个环境试试。

41

42

还好吧，目前没遇到坑，用的挺香

43

45

prisma 需要一个二进制文件，感觉特别不好，我试用了一下就转 drizzle 了

46

@BeautifulSoap #13 虽然我主力用 drizzle ，但是 drizzle 的文档确实很垃圾，而且感觉现在的 LLM 对于 drizzle 的理解不是很好

48

1. Vona ORM 支持“临时或一次性的连表查询”
2. Vona ORM 支持“自动推断生成 DTO”。Prisma 不能优雅的支持 DTO 。如果不能像推断类型一样自动推断出 DTO ，那么，我们就仍然需要手工创建 DTO 。随着业务的增长，复杂的表间关系会让手工补充 DTO 的工作日益繁重。而 Vona ORM 就解决了这个痛点问题： https://www.v2ex.com/t/1150216