数据库操作（插入、更新、删除）后检查受影响的行数是否过大？答案

【问题标题】：Is checking rows affected count after database action (insert, update, delete) overkill?数据库操作（插入、更新、删除）后检查受影响的行数是否过大？
【发布时间】：2012-04-30 14:19:40
【问题描述】：

最近在我一直在开发的应用程序中，我一直在检查受数据库插入、更新、删除影响的行数，并在数量意外时记录错误。例如，如果从 ExecuteNonQuery() 调用返回的行数不是 1 行，则对一行进行简单的插入、更新或删除，我将认为这是一个错误并记录它。此外，我现在在键入此内容时意识到，如果发生这种情况，我什至不会尝试回滚事务，这不是最佳实践，绝对应该解决。无论如何，这里的代码来说明我的意思：

我将有一个调用 db 的数据层函数：

public static int DLInsert(Person person)
{
    Database db = DatabaseFactory.CreateDatabase("dbConnString");

    using (DbCommand dbCommand = db.GetStoredProcCommand("dbo.Insert_Person"))
    {
        db.AddInParameter(dbCommand, "@FirstName", DbType.Byte, person.FirstName);
        db.AddInParameter(dbCommand, "@LastName", DbType.String, person.LastName);
        db.AddInParameter(dbCommand, "@Address", DbType.Boolean, person.Address);

        return db.ExecuteNonQuery(dbCommand);
    }
}

然后是业务层调用数据层函数：

public static bool BLInsert(Person person)
{
    if (DLInsert(campusRating) != 1)
    {
        // log exception
        return false;
    }

    return true;
}

在代码隐藏或视图中（我同时做 webforms 和 mvc 项目）：

if (BLInsert(person))
{
    // carry on as normal with whatever other code after successful insert
}
else
{
    // throw an exception that directs the user to one of my custom error pages
}

我使用这种类型的代码越多，我就越觉得它是矫枉过正的。特别是在代码隐藏/视图中。是否有任何正当理由认为简单的插入、更新或删除实际上不会修改数据库中正确的行数？只担心捕获实际的 SqlException 然后处理它，而不是每次都对受影响的行进行单调检查是否更合理？

谢谢。希望大家能帮帮我。

更新

感谢大家花时间回答。我还没有 100% 决定今后将使用什么设置，但这是我从您的所有回复中得出的结论。

相信 DB 和 .Net 库可以处理查询并按照设计的方式完成工作。
在我的存储过程中使用事务来回滚任何错误的查询，并可能使用raiseerror 将这些异常作为 SqlException 抛出回 .Net 代码，它可以通过 try/catch 处理这些错误。这种方法将取代有问题的返回码检查。

我遗漏的第二个要点会有什么问题吗？

【问题讨论】：

标签： c# asp.net sql-server

【解决方案1】：

我想问题变成了，“你为什么要检查这个？”如果只是因为您不信任数据库来执行查询，那么这可能是矫枉过正。但是，可能存在执行此检查的合乎逻辑的理由。

例如，我曾在一家公司工作，该公司使用此方法检查并发错误。当从数据库中获取要在应用程序中编辑的记录时，它将带有LastModified 时间戳。然后，数据访问层中的标准 CRUD 操作将在执行 UPDATE 时包含 WHERE LastMotified=@LastModified 子句并检查记录修改计数。如果没有更新记录，则假定发生了并发错误。

我觉得并发检查有点草率（尤其是关于假设错误性质的部分），但它为业务完成了工作。

在您的示例中，我更关心的是如何实现这一点的结构。从数据访问代码返回的1 或0 是一个“幻数”。应该避免这种情况。它将数据访问代码中的实现细节泄漏到业务逻辑代码中。如果您确实想继续使用此检查，我建议将检查移至数据访问代码中，如果失败则抛出异常。一般来说，应该避免返回码。

编辑：我刚刚注意到您的代码中还有一个潜在的有害错误，这与我上面的最后一点有关。如果 有多个 记录被更改怎么办？它可能不会发生在INSERT 上，但很容易发生在UPDATE 上。代码的其他部分可能假设!= 1 表示没有更改记录。这可能会使调试变得非常有问题:)

【讨论】：

赞成关于返回码的评论。他们是邪恶的。我与两个开发人员一起在不同的项目上工作，一个使用 1 作为成功，另一个使用 1 作为失败。乱七八糟的东西。
@BrendonDugan：确实，现在不需要返回码，至少在 .NET 世界中不需要。异常是方法的完全有效的退出路径，旨在携带有关错误的有用信息。我认为，与返回码最接近的东西是结构相似或自动生成的服务的通用返回类型（某种通用的IResponse）的想法。它可能包含类似Success 标志和/或Errors 集合之类的内容。
我明白你关于返回码和 != 1 的观点。我想我只是不信任数据库，所以这些额外的检查可能确实是矫枉过正。
@ryanulit：在那种情况下，如果您只是不信任数据库，您怎么能信任记录修改后的结果呢？ :)
@David，我通常会返回某种类型的结构，其中包含一个成功标志 (bool)、一个错误字符串，然后是需要返回的任何其他数据。

【解决方案2】：

一方面，大多数情况下，一切都应该按照您期望的方式运行，而在这些时候，额外的检查不会向您的应用程序添加任何内容。另一方面，如果确实出了问题，不知道它意味着问题可能会在你注意到它之前变得相当大。在我看来，一点点额外的保护是值得付出一点点额外努力的，特别是如果你实现了故障回滚。它有点像你车里的安全气囊……如果你从不撞车，它并没有真正的用途，但如果你这样做，它可以挽救你的生命。

【讨论】：

【解决方案3】：

我一直更喜欢在我的存储过程中使用raiserror 并处理异常而不是计数。这样，如果您更新 sproc 以执行其他操作，例如日志记录/审计，您不必担心检查行数。

虽然如果您喜欢在代码中进行第二次检查，或者不想处理异常/raiserror，但我已经看到团队在数据库中的每个存储过程成功执行存储过程时返回 0，否则返回另一个数字。

【讨论】：

【解决方案4】：

这绝对是矫枉过正。您应该相信您的核心平台（.Net 库、Sql Server）可以正常工作——您不必担心这一点。

现在，您可能想要测试一些相关的实例，例如事务是否正确回滚等。

【讨论】：

【解决方案5】：

如果需要检查，为什么不在数据库本身内进行检查呢？您可以避免往返，并且它是在一个更“集中”的阶段完成的 - 如果您签入数据库，您可以确保它被任何访问该数据库的应用程序一致地应用。而如果您将逻辑放在 UI 中，那么您需要确保访问该特定数据库的任何 UI 应用程序都应用正确的逻辑并始终如一地执行。

【讨论】：