最近我一直在想。假设我们正在用JSF + Spring + JPA/Hibernate（或者其他任何技术）做web应用程序，并假设我们有一个“User”实体。我们希望用户拥有唯一的登录名。如果我们想这样做，那么我们可以在“登录”列上放置一个@UniqueConstraint，但是我们的应用程序仍然需要在用户注册期间检查用户输入是否有效（唯一），没有这个输入并且只有DB约束我们只会得到一个错误。这让我想到，数据库约束是否真的有必要/有帮助？只有当我们能够给他们带来任何好处时，我才会想到他们会有人试图破解我们（但我猜我们的应用程序应该是SQL注入证明），或者我们尝试手动更改数据库内容（不应该真的发生）。事实上，现在我想到了，一般必要/良好实践中的数据库约束？像绳子等对DB有独特的限制吗？
对于我来说，断然是，从97看到Database as a Fotress丹泽的lenght思软件架构师应该知道。他说比我好得多。
真的很喜欢这个链接，谢谢！ – 2010-09-02 15:38:30
虽然所有的文章都是*开放源代码*，所以你可以在wiki上免费阅读它们 – 2010-09-02 15:41:44
是的，他们是。他们在最低级别执行数据完整性。
您可能需要手动更改数据库的内容（即升级到新的版本）
你可能会忘记检查你的代码中的一些限制。
你可以看看这个像客户端/服务器验证。你的程序是客户端，db是服务器。大多数情况下，客户端验证就足够了，但是您必须进行服务器验证，以防出现问题。
我认为一个数据人会说这两个都是绝对必要的。您的问题假设您的中间层应用程序代码将永久存在于该数据库的前面。
事实是，中间层应用程序来来去去，但数据永远存在。
在模式设计中，没有远离列的长度。我想你在问中层是否是强制执行它们的好习惯。也许不是，但它们是数据库的关键。
通常，当您声明一组列是唯一的时，它就是您想要查询的内容 - 因此无论如何它应该最有可能被编入索引。
是的，你的应用程序应该做适当的检查，但是如果错误发生了，该怎么办？如果你的数据库知道一些东西是唯一的，至少你知道你不会存储无效数据（或者不是非常“无效”的数据，比如重复的数据是唯一的）。无论如何，你可以提出相反的问题：你花费什么？
约束，无论是独特的还是外来的，不仅强制数据完整性，而且它们具有性能影响。在没有这些“非正式”常量的知识的情况下，数据库优化器将对如何执行语句做出不可预知的决定。
如果你想要有不好的数据，那么取消数据库中的唯一约束。自从20世纪70年代以来，我一直在处理数据库，并且查询或导入了存储在数百个数据库中的数据。我从来没有在数据库中看到在应用程序级别设置不当的数据。除应用程序之外，许多其他应用程序都会触发数据库（从其他系统导入数据，快速更新prod数据以修复从查询窗口，其他应用程序运行的数据问题等）。很多时候应用程序被替换，约束都会丢失。
但还是我们的应用有用户注册过程中检查 的 用户的输入是否是有效的（唯一的）与否， 没有说，只与DB 约束，我们将简单地得到一个 错误。
这是我读过的最有趣的东西。你只是得到一个错误？这真的只是你需要的权利？曾听说过错误陷阱？试试Catch响铃吗？
对于您的应用程序“检查”，它实际上非常反效。数据库将会检查约束条件，为什么要这样做呢。该应用程序应该插入行，就好像它会很好。数据库将检查唯一性并在失败时提出错误...您的应用程序应该捕获该错误，并执行您现有支票中的任何操作。
这些书很不错，因为我使用自定义的JSF异常处理程序来重定向我每次捕获一个Exception时都会转到page_not_found.jsf，并且由于ConstraintViolationException是Exception的一个子类，它也会被捕获并重定向到页面。不太确定我的用户会对此感到满意。 – 2010-09-02 17:06:48
依靠从数据库抛出的错误通常意味着你一次只能得到一个错误，导致糟糕的用户体验。如果您预先检查您的所有问题，可以一次显示给用户。 – Shlomo 2010-09-02 22:05:27
是的。只要抓住关键违规错误，关键约束就能为您完成工作，而不必额外承担额外的检查费用。
有没有人真的认为在一个攻击必须通过一个特定的不同的载体第一个假设下留下一个攻击矢量是否可以开放？还是有人写这样的文章是为了挑衅和激发讨论？ – bbadour 2010-09-03 13:48:36