Sql 对所有内容进行后端（数据库端）验证是否切实可行？

对于后端验证，我的意思是，在-触发器、检查、过程（插入、更新、删除）等过程中。 它们现在有多实际或必要，而现在大多数验证都是在前端严格处理的有多少后端验证对程序有益？后端验证是否应该忽略一些小事情

---

例如：假设我们有一个年龄障碍的人输入数据。这可以在后端使用触发器或在“年龄”列中进行检查。它也可以在前端完成。因此，当前端有严格的年龄验证时，是否有必要进行后端验证？

后端验证是必要的

---

如果前端使用JavaScript验证，并且用户在浏览器中禁用JavaScript，则验证将关闭。因此，需要进行后端验证。

如果您担心安全性，则应在服务器上验证所有内容，以防止有人创建替代客户端来访问/操作您的数据库。前端也是必要的，因为它可以提高效率，并防止使用不适当的数据访问服务器。

在数据库上放置约束。这不是业务验证，更像是数据验证，例如，外键约束，或者确保主键是唯一的。它确保你的数据是一致的

您正在谈论的验证是业务验证，这种验证应该在您的业务层中，例如在您的域中，并且应该是验证的主要来源。如果这些规则发生更改，您将在业务层中修改它们，您的所有客户机都将立即受到影响

在UI中，您还可以/应该执行基本的输入验证，如检查必填字段或电子邮件地址的有效性；并在此基础上更新或禁用UI控件。我想说，这是一种不会改变（很多）的验证。

古老的答案：视情况而定

这取决于你的需要。如果用户将直接修改数据库，我认为您绝对需要约束您的数据库。也就是说，大量数据库仅由web应用程序修改。虽然您肯定需要在web应用程序本身中进行服务器端验证，因为用户可以绕过您的web页面，但您可能不需要数据库约束

---

为了方便客户，您仍然应该在客户端进行验证。

这是一个概念性问题。通常，现代程序分为三层：

介绍

业务逻辑

数据库

通常，第1层可以选择验证现代应用程序中的所有输入，为用户提供有关可能问题的快速反馈（例如，JS弹出窗口说“这不是有效的电子邮件地址”）

第2层始终必须进行全面验证。它是后端的网关，可以检查复杂的关系约束。它确保没有损坏的数据能够以任何方式进入数据库，并根据应用程序的约束进行验证。这些约束通常比您可以在数据库中检查的约束更复杂（例如，荷兰的银行账号必须是3到7个数字，或9或10，并匹配a）

第3层可以进行验证。如果只有一个“客户机”，它本身就不是必要的，如果有更多（特别是如果同一数据库中有“不太受信任”的用户），它肯定也应该在数据库中。如果应用程序是任务关键型的，那么还建议使用触发器和约束在数据库中进行全面验证，以防止业务逻辑中出现错误。数据库的工作是确保其自身的完整性，而不是遵守特定的业务规则

这个问题没有明确的答案，这取决于您的应用程序的功能以及它的重要性。在银行应用程序中-在所有3个级别上进行验证。在互联网论坛中-只在需要的地方检查，并为额外用户提供性能优势。

这可能有助于：

前端（接口）验证用于数据输入帮助和上下文消息。这确保了用户拥有无障碍的数据输入体验；并将验证正确性所需的往返次数降至最低

应用程序级验证用于业务逻辑验证。这些值是正确的，但它们是否有意义。这就是你在这里所做的验证，你的大部分努力应该在这方面

数据库不做任何验证。它们提供了约束数据的方法，并且应该确保约束的范围。引用完整性确保查询（尤其是跨表查询）按预期工作。就像没有数据库服务器会阻止您在数字列中输入

4000

，它也不应该是检查年龄是否小于40岁的地方，因为这不会影响数据的完整性。但是，确保被删除的行不会留下任何孤立项—这是引用完整性，应该在数据库级别强制执行

---

我认为你把服务器端验证和数据库约束搞错了。前端是不够的。为了可用性，必须尽最大努力进行后端验证和前端验证。实际上，我把服务器端验证作为前端验证，几乎没有任何好的实践适用于“一切”。在某些情况下，您最好修改规则。+1对于数据库的明确部分，不检查业务规则，而是检查内部完整性。值得一提的是，许多关键任务数据库也会检查诸如“年龄必须在0到10岁之间”之类的内容