数据访问层两次DB操作vs放任DB操作失败的方案抉择

我采用router->controller->service->data access架构构建REST API，发现多数教程和示例项目在DAO层执行创建/更新操作时，都会遵循「先从数据库检索现有数据，再执行创建或更新记录」的流程。比如freeCodeCamp的Node.js REST API教程里的这段代码：

const createNewWorkout = (newWorkout) => {
  try {
    const isAlreadyAdded =
      DB.workouts.findIndex((workout) => workout.name === newWorkout.name) > -1;
    if (isAlreadyAdded) {
      throw {
        status: 400,
        message: `Workout with the name '${newWorkout.name}' already exists`,
      };
    }
    DB.workouts.push(newWorkout);
    saveToDatabase(DB);
    return newWorkout;
  } catch (error) {
    throw { status: error?.status || 500, message: error?.message || error };
  }
};

const updateOneWorkout = (workoutId, changes) => {
  try {
    const isAlreadyAdded =
      DB.workouts.findIndex((workout) => workout.name === changes.name) > -1;
    if (isAlreadyAdded) {
      throw {
        status: 400,
        message: `Workout with the name '${changes.name}' already exists`,
      };
    }
    const indexForUpdate = DB.workouts.findIndex(
      (workout) => workout.id === workoutId
    );
    if (indexForUpdate === -1) {
      throw {
        status: 400,
        message: `Can't find workout with the id '${workoutId}'`,
      };
    }
    const updatedWorkout = {
      ...DB.workouts[indexForUpdate],
      ...changes,
      updatedAt: new Date().toLocaleString("en-US", { timeZone: "UTC" }),
    };
    DB.workouts[indexForUpdate] = updatedWorkout;
    saveToDatabase(DB);
    return updatedWorkout;
  } catch (error) {
    throw { status: error?.status || 500, message: error?.message || error };
  }
};

但数据库操作会消耗较多服务器资源，我想知道：直接尝试创建/更新操作、在必要时（如主键已存在、更新缺少必填字段等）捕获操作失败的错误，或是将逻辑封装到数据库优化的存储过程中，这两种方案是不是比先查后操作更优？

先分析「先查后操作」模式的问题 #

• 性能损耗：两次数据库交互（查询+写入）会增加网络往返开销和数据库负载，高并发场景下这个问题会被放大。
• 竞态条件风险：比如两个请求同时检查同一个唯一字段（比如workout名称），都通过校验后执行写入，最终会生成重复数据，破坏业务唯一性规则。

方案一：直接尝试操作并捕获数据库错误 #

这是大部分场景下的最优选择，优势很明显：

• 减少数据库交互：只需要一次写入操作，性能更优。
• 原子性约束保障：把唯一性、非空等校验交给数据库原生约束（比如给name字段加唯一索引），数据库层面的约束是原子性的，能彻底避免竞态条件。
• 代码更简洁：不需要提前查询的冗余逻辑，直接执行写入，捕获错误后转成对应的业务提示（比如唯一键冲突返回400，提示名称已存在）。

需要注意的点：

• 要熟悉目标数据库的错误码：比如MySQL的1062对应唯一键冲突，PostgreSQL的23505对应唯一约束违反，需要把这些错误码映射成符合业务的HTTP状态码和提示信息。
• 必须提前在数据库中配置好约束：比如唯一索引、非空约束、外键约束等，否则数据库不会抛出对应的错误，导致业务逻辑出现漏洞。

方案二：使用数据库存储过程 #

这种方案适合特定场景，优缺点都很突出：

• 优势：
  • 减少应用层与数据库的交互次数：把查询+写入的逻辑封装在数据库内部执行，复杂逻辑下性能提升明显。
  • 数据库原生优化：存储过程经过预编译，数据库会针对性优化执行计划，效率更高。
  • 逻辑统一：多个应用服务可以复用同一个存储过程，保证业务逻辑的一致性。
• 劣势：
  • 开发维护成本高：存储过程的调试、版本控制比应用层代码麻烦，需要具备数据库层面的技能。
  • 耦合性强：业务逻辑与数据库绑定，后续切换数据库（比如从MySQL到PostgreSQL）会非常困难。
  • 扩展性差：修改逻辑需要改动存储过程，会影响所有依赖该过程的服务。

总结建议 #

• 绝大多数业务场景下，直接尝试操作并捕获数据库错误是最优解：兼顾性能、代码简洁性，还能利用数据库原生约束保证数据一致性，符合现代API开发的最佳实践。
• 如果是涉及多表关联、大量数据处理的复杂业务逻辑，且数据库不会轻易切换，可以考虑使用存储过程。
• 尽量避免「先查后操作」的模式，尤其是高并发场景，不仅性能差，还存在数据一致性风险。

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