在使用数据库进行存储的单用户桌面应用程序中，是否需要对数据库执行数据验证，还是可以在代码中执行此操作？什么是最佳实践，如果没有，那么这两种可能性的优缺点是什么？
答案 0 :(得分：9)
最佳做法是两者兼而有之。数据库应负责确保其自身的状态有效，并且程序应确保它不会将垃圾传递给数据库。
缺点是你必须编写更多代码，并且你有额外的额外运行时间开销 - 这两者通常都不是特别好的理由。
优点是数据库确保了低级别的有效性，但是程序可以帮助用户输入有效数据，而不仅仅是从数据库传回错误 - 它可以提前介入并提供UI提示（例如着色无效）文本字段为红色，直到它们正确完成，等等）
- 修改（从评论中提取更多信息） -
在许多情况下，智能方法是在每端编写数据驱动的验证器，并使用共享数据文件（例如XML）来驱动验证。如果验证规范发生更改，则只需编辑描述文件，验证的两端将同步更新。 （没有代码更改）。
答案 1 :(得分：6)
你们两个都做。
数据验证的最佳实践是清理程序对数据库的输入。但是，这并不能成为数据库拥有自己的验证的借口。在代码中编写验证仅考虑托管环境中生成的增量。它不会考虑数据库损坏，管理错误以及数据库将被多个应用程序使用的远程/未来可能性，在这种情况下，应在此新应用程序中复制应用程序级数据验证逻辑。
您的数据库应该有自己的验证例程。您不必将它们视为清理传入数据，就像运行完整性检查/约束/断言一样。数据库中任何时候都不应包含无效数据。这就是完整性约束的全部要点。
总而言之，您同时执行以下两项操作：
答案 2 :(得分：5)
在数据到达数据库之前，您应始终在代码中进行验证。
答案 3 :(得分：3)
数据的持续时间比应用程序长。它挂了很多年。即使您的应用程序不处理监管机构或执法机构感兴趣的数据，情况也是如此，但那些人感兴趣的数据范围不断增加。
与组织（报告，数据仓库，数据中心，Web服务）之间共享数据或在组织之间交换数据比在一个应用程序共享多个数据库时更常见。此类交换可能涉及其他机制，用于加载数据以及提取除前端应用程序之外的数据，这些应用程序理论上拥有该模式。
因此，如果您只想将数据验证规则放入数据库后进行编码。如果你喜欢belt'n'braces也把它们放在GUI中。
答案 4 :(得分：1)
在尝试存储数据之前检查数据不是很明智吗？数据库连接和资源很昂贵。尝试确保在将数据发送到数据库之前验证数据有某种逻辑。我见过有些人在前端做过，有些人在后端做，有的甚至是两个。
创建程序集或验证层可能是个好主意。验证数据，然后将其发送到db。
答案 5 :(得分：0)
请在申请表中！
很难将sqlerror -12345转换成对终端用户来说意味着什么的消息。在许多情况下，当数据库获取数据时，您的用户可能已经很久了（例如，我点击提交然后查看我今天在stackoverflow中获得了多少票数。）
第一个优先事项是在将数据发送到数据库之前验证应用程序中的数据。
第二个优先级应该是验证/屏蔽前端的数据，以防止用户输入无效数据或至少立即警告他们数据不正确。
第三个优先级（如果应用程序足够重要并且您的预算足够大）将由数据库本身验证通过constriants和触发器等进行的任何插入和更新的正确性。