TypeScript 写 postgre sql 的选择

Slonik vs kysely 的比较

为什么应该停止使用查询构建器，例如knex sql

1. 增加了不必要的抽象，sql 在1974年就已经存在。javascript不是用来做这个的。
2. 对于静态sql语句，动态生成出静态sql语句是没有必要的。
3. 对于sql查询构件器减少了sql的学习周期的观点，事实上你用数据库绝对掌握sql语句。减少一个抽象对于数据库人员来说，减少了认知成本，他们对数据库的熟悉程度可以加入写作。
4. 对于sql查询构件器可以轻松切换数据库的观点，事实上一个应用的生命周期极少切换数据库
5. 对于sql查询构件器不会产生语法错误的观点，在你写sql的过程中，你会遇到大量的错误，这没什么大不了，但不是增加抽象层的原因
6. knex默认安全？文章举了一个反例。

如何使用 Slonik

使用 Slonik 考虑是？

1. 作者称书写 raw 可以粘贴到查询器里立马得到测试和结果。但是根据我的使用经验，不论在代码中使用Slonik书写的 raw sql 或者是 query log，都是无法立刻在数据库中使用的。由于打印的日志是原始sql，拼接的绑定参数都是分开打印的，要调试的话，用户需要操作粘贴多次到数据库控制台中。
2. 作者称对于字段或者表名都需要增加 identify，来进行隔离，防止动态注入造成不安全因素。对于静态sql使用字面量，不可更改。
   • 防止不了解上下文的人轻易更改表名或者字段
     • 可维护性就降低了，无法用lsp得到字段是否是对的。

思考

我用了一段时间的 Slonik，起初 raw sql 的思路与我的偏好不谋而合，后续我发现这种书写方式太耗费时间了， raw 自己写，定义自己写，字段也需要一次转换。在这个基础上再封装与库的思路偏移。Slonik 使用上的体验不好用。 在鼓吹 raw sql 的好处里面，唯一没提到的就是效率。事实上，安全和效率有时候需要权衡。书写 raw sql 是繁杂的。Slonik 还需要定义 结果 的类型，虽然可以使用 zod 简化类型的书。写 有没有什么方式快速生成 curl 的代码，并且这个代码具有可读性、可维护性、易使用性。 可维护性指的是 数据库字段变更以后，如果数据库字段和代码字段不符合的话，能告知代码哪里出错。

我希望的数据库到代码的路径是，由数据库产生声明定义，声明定义产生代码或代码提示或类型检查。我找到的答案是 kysely

附录

kysely

• 缺点：需要提前定义表，但是可以通过 kysely codegen 来完成。
• 优点：完善的自动完成功能，提示功能。sql 执行结果带有类型定义。

rust 查询结果不绑定，需要一列一列获取。

• https://github.com/SeaQL/sea-query#query-select
• https://github.com/SeaQL/sea-query/blob/master/examples/sqlx_postgres/src/main.rs

kotlin 也有这样的情况，为什么他们不能做成 sql 执行以后直接获得有类型定义的结果？

因为这种库都比较底层，如果需要达到这种效果，需要提前定义表，