防止错误的数据输入

Question

将数据验证完全委托给数据库引擎约束是一种好的做法吗？

从应用程序验证数据不会阻止无效插入从另一个软件（可能由另一队用其它语言编写）。使用数据库约束可以减少需要担心无效输入数据的点。

如果你把验证无论是在数据库和应用程序，维护变得无聊，因为你必须更新谁知道有多少应用程序代码，增加了人为错误的可能性。

我只是没有看到这一点做得很好，看着自由软件项目的代码。

Answer 1

这是最好的，如果可能的话，在你的数据库中指定的验证规则，并使用或写一个框架，使这些规则冒泡到您的前端。 ASP.NET动态数据帮助解决这个问题，并且有一些商业库可以让它更容易。

这可以为简单的输入验证（如数字或日期）和像外键约束的相关数据这样做。

总之，这个想法是在一个地方定义规则（数据库大部分时间），并在其他层中有代码来执行这些规则。

Answer 2

我想说这可能是一种不好的做法，取决于查询失败时会发生什么。例如，如果您的数据库可能会抛出一个由应用程序智能处理的错误，那么您可能会确定。

在另一方面，如果你不把任何验证在你的应用程序，你可能不会有什么不好的数据，但你可能有用户认为他们进入的东西，不会被保存。

Answer 3

在输入时间验证。在将其放入数据库之前再次验证。并有数据库约束，以防止不良输入。尽管如此，你仍然可以下注，坏数据仍然会进入你的数据库，所以当你使用它时再次验证它。

好像每一天，因为他们做了他们在形式或更糟的所有验证，使用Javascript，人们找到了一种方法来绕过它的一些Web应用程序被黑客攻击。你必须警惕这一点。

偏执吗？我？不，只是经历过。

Answer 4

尽可能在数据库端执行尽可能多的数据验证，而不会影响其他目标。例如，如果速度有问题，您可能需要考虑而不是使用外键等。此外，某些数据验证只能在应用程序端执行，例如，确保电子邮件地址具有有效域。

Answer 5

将逻辑留给数据库的缺点是增加了该特定服务器上的负载。 Web和应用程序服务器相对容易向外扩展，但数据库需要特殊技术。作为一般规则，将尽可能多的计算逻辑放入应用程序层并尽可能简化与数据库的交互是一个好主意。

随着中说，有可能是您的应用程序可能不需要担心这样重的可扩展性问题。如果您是某些数据库服务器负载在可预见的将来不会成为问题，那么请继续并将约束放在数据库上。通过将验证逻辑保存在中央位置，您完全可以正确地改进整个系统的组织和简单性。

Answer 6

从数据库中进行数据验证的另一个缺点是通常你不会在每种情况下验证相同的方式。实际上，它通常取决于应用程序逻辑（用户角色），有时您可能想要完全绕过验证（cron作业和维护脚本）。

Answer 7

除了SQL注入和输入外，还有其他一些问题。每当接受用户输入时，您应该采取最防御姿态。例如，用户可能能够将图像链接输入到文本框中，该文本框实际上是一个运行一些令人讨厌的PHP脚本。

如果你设计好你的应用程序，你不应该费力地检查所有的输入。例如，您可以使用一个表单API来处理大部分工作，而数据库层则完全相同。

这是漏洞的基本检查一个很好的资源：

http://ha.ckers.org/xss.html

Answer 8

它来得太迟通过得到的数据到数据库，为用户和应用程序提供有意义的验证时间。你不希望你的数据库做所有的验证，因为这会让事情变得相当不错，而且数据库不能清楚地表达逻辑。同样，随着您的增长，您将会编写更多的应用程序级事务来补充您的数据库事务。

Answer 9

我发现在应用程序中进行验证，而不是在数据库中，效果很好。当然，所有的交互都需要通过你的应用程序。如果你有其他的应用程序可以处理你的数据，你的应用程序将需要支持某种API（希望是REST）。

Answer 10

我不认为有一个正确的答案，这取决于您的使用。

如果您打算使用的系统非常多，可能会导致数据库性能成为瓶颈，那么您可能需要将验证责任移到易于扩展的前端多个服务器。

如果您有多个应用程序与数据库进行交互，那么您可能不想在多个应用程序中复制和维护验证规则，因此数据库可能会更好。

您可能需要一个更加清晰的输入屏幕，当他们尝试保存一条记录时，不仅仅会触及用户的验证警告，或许您想在输入数据后验证一个字段，并且会丢失焦点;或者甚至在用户键入时，在验证失败/通过时更改字体颜色。

也与约束有关，是对可疑数据的警告。在我的应用程序中，我对数据库有严格的约束（例如，有人在出生日期之前无法开始工作），但是在前端有可能是正确的，但可疑的数据警告（例如八年-old开始工作）。