Rust中ORM框架选择? - Reddit

22-05-17 banq

1、 我曾经使用过Diesel、SQLx和Cornucopia https://github.com/LouisGariepy/cornucopia。
当SQLx出现的时候,我立即抛弃了Diesel,仅仅使用SQL作为与数据库对话的语言对我来说是最有意义的。
SQLx增加了你的增量构建时间。
我现在使用Cornucopia,它有和SQLx一样的检查,但对构建时间的影响要小得多。


2、Diesel 目前(至少在标准设置下)不支持异步。除此之外,它很棒,但这对我来说太大了。
我也尝试过tokio postgres,但它缺少连接池。
在我看来,目前最好的选择,也是我目前在生产中使用的,是sqlx


3、sea-orm 很棒并且建立在 sqlx 之上
我已经使用sqlx、sea和diesel有一段时间了。
我可以说,尽管sea真的很好,但它还没有成熟到可以在PROD中使用(我已经在他们的GH上报告了几个问题),但如果你不想做任何严重的事情,它是比较好的。
Diesel的主要问题是JOIN操作,几乎不可能只用Diesel来做这些操作。
我所尝试和使用的最令人愉快和准备就绪的PROD是SQLx,从我的经验来看,使用它的缺点很少。主要是要自己写SQL查询,但另一方面,在我看来,它也更具有可读性和优化性。另一个缺点是,如果你决定迁移你的数据库引擎,你需要重新写所有的查询。


4、SQLx乍看之下似乎是一个非常好的解决方案。但至少从我的观点和我看一些例子的经验来看,有以下几个问题。
  • 性能。SQLx + sqlite的性能始终比Diesel或Rusqlite慢(而且不是小幅度的)。这也适用于任何建立在SQLx之上的东西,比如sea-orm。问题似乎是他们的异步优先的方法与sqlite的工作方式不一致。
  • "动态查询"。SQLx的编译时查询检查宏要求在编译时就知道整个查询。这意味着一旦你包含一些动态部分,就不可能再检查这些查询。(这里的动态是指简单的结构,如基于可变大小的容器的IN (?, ?, ?) 列表,因为这些需要可变数量的绑定调用,这导致了动态查询。) Sea-orm通过拥有一个查询生成器来 "解决 "这个问题,但这并没有提供与SQLx或Diesel相同的保证水平。
  • "类型检查方法的局限性"。乍一看,似乎SQLx应该能够静态地检查复杂的查询。在实践中,有些查询他们会推断出错误的列类型。例如,这发生在NOT NULL约束和LEFT JOIN。他们为这个问题提供了解决方法,但这需要手动为查询注释额外的类型信息。(同样,这并不适用于sea-orm,因为他们提供了一个动态查询生成器,在编译时执行有限的类型检查)。


所有写好的Diesel本身显然也不是银弹解决方案。如果出了问题,Diesel往往会在编译时产生大量的错误信息,以表明某些查询是无效的。虽然这能抓住根本问题,但这些错误信息需要一些实践来了解那里发生了什么。此外,Diesel试图在编译时通过类型系统进行检查。这可能会限制真正的动态结构(例如,你指定一个动态的列列表作为选择子句)。

猜你喜欢