Node-postgres多查询最佳实践：发票创建时多表插入方案抉择

问题描述 #

我正在学习Postgres/SQL，设计的发票数据库包含recipients（收件人）、drafts（发票草稿）、items（发票明细行）三张表。创建发票时需要向这三张表分别插入数据，目前有两种实现方案：

方案一：使用CTE的单复杂查询 #

db.query('
WITH new_recipient AS (
    INSERT INTO 
        recipients(...) 
    VALUES (...)
    RETURNING id AS recipient_id, user_id
), new_draft AS (
    INSERT INTO drafts(user_id, recipient_id)
    SELECT user_id, recipient_id FROM new_recipient
    RETURNING id AS draft_id
)
SELECT new_recipient.*, new_draft.* FROM new_draft, new_recipient'
,[...])

方案二：拆分多次查询 #

const data = await pool.query(
    `INSERT INTO recipients (...) VALUES (...) RETURNING *`,
    [....]
);

const draft = await pool.query(
    `INSERT INTO drafts (recipient_id, ...) VALUES ($1, ...) RETURNING *`,
    [data.rows[0].recipient_id, ...data]
);

我倾向选择第二种方案，因为它可读性更强、实现更简单，但想了解是否存在选择第一种方案的理由，比如拆分多次查询是否会导致性能下降？

选择方案一的核心理由 #

1. 原生保证事务原子性 #

方案一的CTE插入在单个Postgres查询中完成，Postgres会自动将整个CTE序列视为一个原子事务：只要任意一步插入失败，所有已执行的插入操作都会自动回滚，不会出现数据不一致（比如只插入了收件人但没生成对应的发票草稿）。

而方案二如果没有手动用事务包裹两次查询，两次插入是独立的——如果第一次插入成功但第二次失败，数据库会留下孤立的recipients记录。即使你手动添加事务代码，方案一的写法更简洁，不需要额外的事务开启/提交逻辑。

2. 减少网络往返开销 #

方案一只需一次应用程序到数据库的请求，而方案二需要两次。在高并发场景下，多次网络往返的延迟累加会显著影响系统吞吐量，尤其是当应用服务器和数据库服务器不在同一机房时，这种差异会更明显。

单条CTE查询的内部执行开销和分两次查询的总开销相差不大，但网络请求的节省是实打实的性能优化点。

3. 简化应用层状态管理 #

方案一不需要在应用层存储中间结果（比如recipient_id），避免了中间数据在应用层被意外修改或丢失的风险，也减少了应用层的状态变量。

方案二的适用场景 #

当然，方案二的可读性和灵活性确实是优势：如果插入过程中需要在应用层做额外的业务判断（比如根据收件人信息生成自定义的发票字段），或者后续需要扩展更复杂的分支逻辑，拆分查询会更易于维护和调试。

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