将数据验证完全委托给数据库引擎约束是不错的做法？
从应用程序验证数据不会阻止从其他软件无效插入（可能由另一个团队用另一种语言编写）。使用数据库约束可以减少需要担心无效输入数据的点。
如果您在数据库和应用程序中都进行了验证，那么维护变得很无聊，因为您必须更新谁知道有多少应用程序的代码，从而增加了人为错误的可能性。
我只是看不到这么做，看着自由软件项目的代码。
答案 0 :(得分：11)
在输入时验证。在将其放入数据库之前再次验证。并有数据库约束来防止输入错误。尽管如此，您仍然可以打赌，不良数据仍然会进入您的数据库，因此在您使用它时会再次验证它。
似乎每天都有一些网络应用被黑客入侵，因为他们在表单中做了所有验证，或者更糟糕，使用Javascript，人们找到了绕过它的方法。你必须要防范这一点。
偏执？我？不，只是经历过。
答案 1 :(得分：5)
最好尽可能在数据库中指定验证规则，并使用或编写一个框架，使这些规则在您的前端冒泡。 ASP.NET动态数据有助于此，并且有一些商业库可以使它更容易。
这可以用于简单的输入验证（如数字或日期）和受外键约束的相关数据。
总之，我们的想法是在一个地方（数据库大部分时间）定义规则，并在其他层中使用代码来强制执行这些规则。
答案 2 :(得分：1)
将逻辑留给数据库的缺点是增加了该特定服务器的负载。 Web和应用程序服务器相对容易向外扩展，但数据库需要特殊技术。作为一般规则，将尽可能多的计算逻辑放入应用程序层并尽可能简化与数据库的交互是个好主意。
话虽如此，您的应用程序可能不需要担心这种严重的可伸缩性问题。如果您某些数据库服务器负载在可预见的将来不会出现问题，那么请继续将约束放在数据库上。您完全可以通过将验证逻辑保持在中心位置来改善整个系统的组织和简化。
答案 3 :(得分：1)
除了输入SQL注入之外，还有其他问题。无论何时接受用户输入，您都应采取最具防御性的姿态。例如，用户可能能够将图像的链接输入到文本框中，该文本框实际上是运行令人讨厌的东西的PHP脚本。
如果您设计好应用程序，则不必费力地检查所有输入。例如，您可以使用Forms API来处理大部分工作，以及一个大致相同的数据库层。
这是用于基本检查漏洞的良好资源：
答案 4 :(得分：1)
当数据到达您的数据库以便为您的用户和应用程序提供有意义的验证时，已经太晚了。您不希望您的数据库执行 all 验证，因为这样会减慢速度，并且数据库不能清楚地表达逻辑。同样，随着您的成长，您将编写更多应用程序级事务以补充数据库事务。
答案 5 :(得分：0)
我认为这可能是一种不好的做法，具体取决于查询失败时会发生什么。例如，如果您的数据库可能抛出一个由应用程序智能处理的错误，那么您可能没问题。
另一方面，如果您未在应用中进行任何验证，则可能没有任何不良数据，但您可能会让用户认为他们输入了无法保存的内容。
答案 6 :(得分：0)
在数据库端实现尽可能多的数据验证，而不会影响其他目标。例如，如果速度是个问题，您可能需要考虑 not 使用外键等。此外，某些数据验证只能在应用程序端执行，例如，确保电子邮件地址有效域。
答案 7 :(得分：0)
从数据库进行数据验证的另一个缺点是，在每种情况下通常都不会以相同的方式验证。实际上，它通常依赖于应用程序逻辑（用户角色），有时您可能希望完全绕过验证（cron作业和维护脚本）。
答案 8 :(得分：0)
我发现在应用程序中而不是在数据库中进行验证效果很好。当然，所有交互都需要通过您的应用程序。如果您有其他应用程序可以处理您的数据，那么您的应用程序将需要支持某种API（希望是REST）。
答案 9 :(得分：0)
我认为没有一个正确的答案，这取决于你的用途。
如果您将拥有一个使用频率非常高的系统，可能会导致数据库性能成为瓶颈，那么您可能希望将验证的责任转移到前端，以便更容易扩展服务器
如果您有多个应用程序与数据库交互，那么您可能不希望跨多个应用程序复制和维护验证规则，因此数据库可能是更好的地方。
您可能需要一个灵活的输入屏幕，当用户尝试保存记录时，它不仅会向用户发出验证警告，您可能希望在输入数据后验证字段并且丢失焦点;或者甚至在用户输入时，在验证失败/通过时更改字体颜色。
还与约束相关，是对可疑数据的警告。在我的应用程序中，我在数据库中有严格的限制（例如某人在出生日期之前无法开始工作），但是在前端对可能正确但可疑的数据发出警告（例如八年 - 开始工作）。