正在从完整性已损坏的数据库中提取数据
本文关键字：数据库 提取 数据 已损坏 完整性 | 更新日期: 2023-09-27 18:23:58
应用程序在从数据库获取数据时是否应该预料到意外情况？假设我们已经在列（int或text）中存储了一个枚举值。当我们从数据库返回值时，我们将该值强制转换为枚举类型。若有人手动更改了数据库中的数据，破坏了数据的完整性，那个么我们的演员阵容会失败呢？
另一个例子是当c#中的数据类型的范围小于数据库中的等效字段时。若有人手动将值放入这个值中，比如说数据库的最大值，那个么应用程序就会抛出超出范围的异常。
我们应该以及如何处理这种例外情况？
编辑：由于大多数答案相似，我将重新表述这个问题。这意味着应用程序中存在异常日志记录。问题是：当用户查询某些数据时，数据已损坏（不是来自应用程序CRUD操作，而是来自外部），从数据库到模型的数据转换将失败，用户将根本得不到数据。在应用程序中有这样的状态是可以接受的吗，因为应用程序本身并没有造成这种状态？
验证数据会大大降低数据获取速度。想象一下，如果每个十进制值超出范围，您需要检查它吗？
我一直认为将任何数据库交互代码放在try...catch块中的数据层中是标准做法，这样您就可以以文明的方式处理此类情况。
我不会检查所有可能发生的情况，但从长远来看，在支持代码时，能够记录异常将非常有用。
在实时系统的情况下，拥有这样的信息总是很好的，尤其是当你可以指责客户篡改了他们不应该拥有的东西时。
编辑
正如我所说，您不能检查所有可能发生的情况，但您可以捕获由某些情况引起的异常，例如将值强制转换为不存在的枚举。
除了极端情况之外，实际上不可能检查超出范围的值，例如字段意外返回为DBNull或无法从数据库数据类型转换为模型数据类型。在这种情况下，处理错误并向用户呈现错误消息或"错误消息"；值未知"；类型指示器应该可以。
这里的问题是，您有一个用户在不使用您的应用程序的情况下更改数据。
您可能已经在数据模型中实现了IDataErrorInfo，特别是为了验证用户输入，如果不在这里查看示例，或者类似的东西。
但是，你无法真正处理"损坏"的数据是有效值的问题，即，如果你的枚举字段被更改为正确的值，但逻辑上不正确的字段，直到你开始使用它，你才会知道它是错误的。
必须采取务实的方法，因为您正确地说过，验证从数据库中检索的数千个甚至数百个值会对性能产生无法接受的影响。
但是说"；出现错误，请与您的系统管理员联系；或者类似的事情在我看来是完全可以接受的。
既然你的数据库在低级别上有容易出错的人，那么你肯定应该执行这样的检查。原因是调试非常昂贵，因此当其中一个错误确实发生时（不可避免地会发生），作为一种防御措施，你应该尽早发现这些错误，而不是让它们传播到你的程序中，在其他地方引起更微妙、更难发现的错误。
如果一个奇怪的值"不可能"进入你的数据库，有人可能会认为这样的检查是不必要的。例如，您可以对数据库列设置列约束。即使在这种情况下，也可能将代码检查作为一种防御措施，除非你认为这种检查会降低系统的性能（他们可能不会）。
这取决于，这通常可能发生吗？
就我而言，我所做的是对事物：
- 记录可执行文件所做的一切（在这种情况下，它可以用来识别它的故障位置）
- 当使用批处理文件运行它时，请检查退出状态，如果不是0（发生错误），请为我发送电子邮件
有了这个，我知道是否发生了什么，我可以证明这不是我的错。
关于你的更新，我只能说这取决于情况！
在我的情况下，我构建关于所提供的功能数据的项目。在所有项目中，我们都有一组客户需要满足的需求（其中一个可能是以某种方式从表中提取的数据）。
客户接受要求，瞧！因此，如果有什么改变，那不是我们的错，我们是安全的，因为客户接受了要求。