存储过程允许从应用程序的角度更好地抽象和分离关注点。在我的公司，有一个传统，即让DBA编写程序并完成所有数据库工作。并且，这是一个主要适用的模型。
作为.NET开发人员，我使用资源文件来聚合我的所有错误/成功/验证消息。这使我能够将我的错误消息标准化和集中化，因此，一旦实现完成并且我们需要记录＆＃34;应用程序消息＆＃34;，该过程是直截了当的。
但是，我们的DBA习惯于在整个过程中散布错误消息，这使得记录系统变得困难。当前的解决方案是始终返回@Result和@Message并使用Redgate工具进行搜索并查找这些变量。然而，这很乏味，听起来并不是一个很好的解决方案。
我想知道是否有任何建议的做法将错误消息集中在数据库端，同时仍然没有降低性能？
答案 0 :(得分：2)
在我们的应用程序中，我们从sproc返回错误代码。这些错误代码是固定的整数，例如如果要求更新的用户标识在数据库中不存在，则返回错误代码10。我们使用这些错误代码作为资源文件中的键来定义针对它们的标准错误消息。
我们还定义了与这些错误代码相对应的枚举，只是为了让我们的生活更轻松