是否必须对DB有独特的约束？

Question

我最近一直在想。假设我们正在使用JSF + Spring + JPA / Hibernate（或任何其他技术）进行webapp，并且假设我们有一个“用户”实体。我们希望用户拥有唯一的登录信息。如果我们想要这样做，那么我们可以在“登录”列上放置一个@UniqueConstraint，但是我们的应用程序仍然需要在用户注册期间检查用户输入是否有效（唯一），没有它，只有数据库约束我们只会得到一个错误。这让我想到，DB约束真的有必要/有帮助吗？只有当有人试图破解我们时，我能想到的唯一两次才会想到（但我想我们的应用程序应该是SQL注入证明）或者我们尝试手动更改数据库内容（不应该真的发生了）。实际上，现在我考虑一下，DB约束一般是必要的/良好实践吗？就像字符串的长度等。

Answer 1

对我来说，断然是，请参阅Dan Chak的Database as a Fotress 97认为每个软件架构师都应该知道。他说这比我做得好得多。

Answer 2

是的，他们是。它们在最低级别强制执行数据完整性。

您可能希望手动更改数据库内容（即升级到新版本）

您可能忘记检查代码中的某些约束。

您可以将此视为客户端/服务器验证。你的程序是客户端，db是服务器。主要是客户端验证就足够了，但是如果出现问题，您必须进行服务器验证。

Answer 3

我认为一个数据人会说两者都是绝对必要的。您的问题假定您的中间层应用程序代码现在和永远都在该数据库的前面。

事实是，中间层应用程序来去匆匆，但数据永远存在。

架构设计中的列长度没有减少。我想你在问中间层执行它们是不是一个好习惯。也许不是，但它们是数据库的关键。

Answer 4

通常当你声明一组列是唯一的时，它就是你想要查询的东西 - 所以它最有可能被索引。

是的，您的申请应该进行适当的检查，但如果错误出现怎么办？如果您的数据库知道某些内容是唯一的，那么至少您知道您不会存储无效数据（或者不是“非常糟糕”的无效数据，例如想要唯一的数据副本）。无论如何，你可以问相反的问题：你花了多少钱？

Answer 5

如果您想获得错误数据，请取消数据库中的唯一约束。自1970年代以来，我一直在研究数据库，并查询或导入存储在数百个数据库中的数据。我从未在数据库中看到过良好的数据，其中约束在应用程序级别上被不正确地设置。除应用程序之外的许多其他内容都会访问数据库（从其他系统导入，快速更新以生成数据以修复从查询窗口运行的数据问题，其他应用程序等）。很多时候应用程序被替换并且约束丢失。

Answer 6

唯一和外来的约束不仅强制数据完整性，而且还具有性能影响。如果不了解这些“非正式”常量，数据库优化器就会对如何执行语句做出不可预测的决定。

Answer 7

  

但我们的申请仍需检查   在用户注册期间是否   用户输入是否有效（唯一），   没有它，只有DB   约束我们只会得到一个   错误。

这是我读过的最有趣的事情。你只是得到一个错误？那真的是你需要的吗？有没有听说过错误捕获？试试Catch响铃吗？

对于您的应用来说，“检查”实际上非常有效。数据库将检查约束，所以为什么要两次。应用程序应该只是插入行，就好像它会好。数据库将检查唯一性并在失败时引发错误...您的应用程序应该捕获该错误并执行您在现有检查中所做的任何操作。

Answer 8

是。只需捕获密钥违规错误，密钥约束将为您完成工作，而不必首先产生额外检查的额外开销。