防止不良数据输入

Question

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

验证应用程序中的数据并不能防止来自另一个软件（可能由另一个团队用另一种语言编写）的无效插入。使用数据库约束，您可以减少需要担心无效输入数据的情况。

如果您在数据库和应用程序中都进行验证，维护就会变得乏味，因为您必须为谁知道有多少应用程序更新代码，从而增加了人为错误的可能性。

我只是没有看到太多这样做，查看自由软件项目的代码。

Answer 1

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

这可以用于简单的输入验证（如数字或日期）和相关数据（如受外键约束的数据）。

总之，其想法是在一个地方（大多数时候是数据库）定义规则，并在其他层中使用代码来强制执行这些规则。

Answer 2

在输入时验证。在将其放入数据库之前再次验证。并且有数据库约束来防止错误的输入。尽管如此，您可以打赌，坏数据仍然会进入您的数据库，因此在使用时再次验证它。

似乎每天都有一些网络应用程序遭到黑客攻击，因为他们以表单或更糟的方式使用 Javascript 进行了所有验证，并且人们找到了绕过它的方法。你必须警惕这一点。

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

Answer 3

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

话虽如此，您的应用程序可能不需要担心如此严重的可扩展性问题。如果你是 肯定 如果数据库服务器负载在可预见的将来不会成为问题，那么就继续对数据库施加约束。您说得非常正确，通过将验证逻辑保留在中心位置，可以提高整个系统的组织性和简单性。

Answer 4

除了输入的 SQL 注入之外，还有其他问题。每当接受用户输入时，您都应该采取尽可能最具防御性的立场。例如，用户可能能够在文本框中输入图像的链接，这实际上是运行一些令人讨厌的东西的 PHP 脚本。

如果您设计得很好，您就不必费力地检查所有输入。例如，您可以使用表单 API 来为您处理大部分工作，并使用数据库层来完成大部分相同的工作。

这是用于基本漏洞检查的良好资源：

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

Answer 5

当数据到达数据库时为用户和应用程序提供有意义的验证时已经太晚了。你不希望你的数据库做 全部 验证，因为这会大大减慢速度，并且数据库不能清楚地表达逻辑。同样，随着您的成长，您将编写更多应用程序级事务来补充您的数据库事务。

Answer 6

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

另一方面，如果您不在应用程序中进行任何验证，则可能不会有任何不良数据，但用户可能会认为他们输入了未保存的内容。

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

我认为没有一个正确的答案，这取决于你的用途。

如果您将拥有一个使用非常频繁的系统，并且数据库性能可能成为瓶颈，那么您可能希望将验证的责任转移到前端，这样更容易通过多个服务器进行扩展。

如果您有多个应用程序与数据库交互，那么您可能不希望跨多个应用程序复制和维护验证规则，因此数据库可能是更好的地方。

您可能想要一个更流畅的输入屏幕，当用户尝试保存记录时，它不仅会向用户发出验证警告，也许您希望在输入数据并且失去焦点后验证字段；或者甚至在用户键入时，在验证失败/通过时更改字体颜色。

与约束相关的还有可疑数据的警告。在我的应用程序中，我在数据库中有硬约束（例如有人无法在出生日期之前开始工作），但随后在前端会对可能正确但可疑的数据发出警告（例如一个开始工作的八岁孩子）。