Node.js应用中使用ORM执行SQL操作的行业最佳实践咨询

场景1：关联数据的分步查询是否属于不良实践？ #

存在User-hasmany-Order-hasmany-Product的关联关系，若要获取某用户的所有产品，ORM本可通过左连接轻松实现，但像以下分步查询的写法是否会被视为不良实践？

const user = await User.getByPk(1);
const orders = await user.getOrders();
const products = await Promise.all( /* 遍历每个订单调用order.getProducts */ )

这种分步查询的原则是否属于公认的代码异味？包裹在事务中是否可行？

解答 #

• 分步查询算不算不良实践，得看数据规模：
  • 如果用户的订单数量很少，这种写法性能影响可以忽略，而且代码逻辑直观易懂，完全没问题。
  • 如果用户订单量很大，这就是典型的N+1查询问题——1次查用户、1次查订单、N次查每个订单的产品，会触发大量数据库请求，严重拖慢性能，属于明确的代码异味，这时候必须换成ORM的关联查询（比如左连接）来减少查询次数。
• 包裹在事务里可行，但没必要：事务的核心是保证操作的原子性，而这里全是读操作，用事务不会提升性能，反而会占用额外的数据库连接资源，纯粹浪费。

场景2：ORM不支持的Postgres功能（如TSVECTOR）如何处理？ #

我想在Postgres中使用TSVECTOR功能，但Sequelize这类ORM似乎不支持该功能。此时是否应尝试通过ORM的原生查询功能实现，还是直接使用postgres.js这类原生客户端？

解答 #

优先用ORM自带的原生查询功能，原因如下：

• 能复用ORM已有的连接池、事务管理、错误处理机制，不用重新配置和维护一套独立的原生客户端逻辑，减少维护成本。
• 以Sequelize为例，你可以用sequelize.query()执行包含TSVECTOR的原生SQL，还能结合ORM的模型定义来处理返回结果，兼顾灵活性和一致性。
• 只有当ORM的原生查询满足不了复杂需求（比如极端复杂的SQL语句、特定Postgres特性的深度交互），或者有极致性能要求时，再考虑引入原生客户端，但要注意尽量保持代码风格统一，避免两套数据库操作逻辑带来的混乱。

内容的提问来源于stack exchange，提问作者ddolce