从完整性破坏的数据库中获取数据答案

【问题标题】：Fetching data from database with integrity broken从完整性破坏的数据库中获取数据
【发布时间】：2012-02-29 22:57:15
【问题描述】：

应用程序在从数据库中获取数据时应该期待意外吗？假设我们在列（int 或 text）中存储了一个枚举值。当我们从数据库返回值时，我们将值转换为枚举类型。如果有人手动更改了数据库中的数据，破坏了数据完整性，所以我们的演员阵容失败了怎么办？

另一个例子是当 c# 中的数据类型的范围小于数据库中的等效字段时。如果有人手动输入这个值，比如说数据库最大值，那么应用程序会抛出超出范围的异常。

我们应该以及如何处理这种异常？

编辑：由于大多数答案都是相似的，我将重新表述这个问题。暗示应用程序中存在异常日志记录。问题是：当用户查询某些数据时，如果数据损坏（不是来自应用程序的 CRUD 操作，而是来自外部），从数据库到模型的数据转换将失败，用户将一无所获。应用中出现这样的状态是否可以接受，因为不是应用本身造成的？

验证数据会大大降低数据获取速度。假设您需要检查每个十进制值是否超出范围？

【问题讨论】：

【解决方案1】：

我一直认为将任何数据库交互代码放在数据层中的 try...catch 块中是标准做法，以便您可以文明地处理此类情况。

我不会检查所有可能发生的情况，但从长远来看，能够记录异常对于支持您的代码很有用。

在实时系统的情况下，拥有此类信息总是好的，尤其是当您可以指责客户摆弄他们不应该拥有的东西时。

编辑

正如我所说，您无法检查所有可能性，但您可以捕获由诸如将值强制转换为不存在的枚举等情况引起的异常。

除了极端值之外，实际上不可能检查超出范围的值，例如字段意外返回为 DBNull 或从数据库数据类型转换为模型数据类型失败。在这种情况下，处理错误并向用户显示错误消息或“VALUE UNKNOWN”类型指示符应该没问题。

这里的问题是您有一个用户在不使用您的应用程序的情况下更改数据。

您可能已经在您的数据模型中实现IDataErrorInfo，专门用于验证用户输入，如果没有，请查看here 的示例，或者类似的东西。

但是你不能真正处理“损坏”的数据是一个有效值，即如果你的枚举字段被更改为一个正确的值，但在逻辑上不正确，直到你开始使用它才知道它是错了。

必须采取务实的方法，因为您说得对，验证从数据库中检索到的数千个甚至数百个值会对性能产生不可估量的影响。

但是在我看来，说“出现错误，请联系您的系统管理员”或类似的话是完全可以接受的。

【讨论】：

【解决方案2】：

既然您的数据库处于低级别，那么您肯定应该执行此类检查。原因是调试非常昂贵，因此当其中一个错误确实发生时（不可避免地会发生），作为一种防御措施，您应该尽早捕获此类错误，而不是让它们传播到您的程序中并导致更微妙的，在其他地方更难找到错误。

如果一个奇怪的值“被证明不可能”进入您的数据库，人们可能会争辩说这样的检查是不必要的。例如，您可以在数据库列上放置列约束。即使在这种情况下，也可能会保留代码检查作为一种防御措施，除非您可以争辩说此类检查会降低系统的性能（它们可能不会）。

【讨论】：

【解决方案3】：

这取决于，这通常可能发生吗？

就我而言，我所做的是对事物：

有了这个，我知道是否发生了什么事，我可以证明这不是我的错。

关于你的更新，我只能说这取决于！

在我的例子中，我构建了有关提供的功能数据的项目。在所有项目中，我们都有一组客户需要批准的要求（其中一个可能是以某种方式来自表格的数据）。

客户接受要求，瞧！因此，如果某些东西发生了变化，这不是我们的错，我们是安全的，因为客户接受了要求。

【讨论】：

@Goran 看看我现在说了什么。
如果我理解你的话，你指的是外部数据源，我说的是我们的应用程序数据库？我不知道你怎么能对这个东西有一套要求？示例：C# 中的 Decimal 字段的精度为 29，SQL Server Decimal 的精度为 38。如果有人在您的数据库中输入一个精度为 38 的值，应用程序将异常中断。您可以与客户就此类问题和类似问题达成什么样的协议？当然，假设数据库在客户网站上。