数据库是否需要唯一的约束?

为了我, 绝对是的 Database as a Fotress 作者:Dan Chak . 他说得比我好得多。

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

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

您可以将其视为客户机/服务器验证。你的程序是客户机,数据库是服务器。大多数情况下,客户机验证已经足够了,但您必须进行服务器验证,以防出现问题。

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

事实是,中间层应用程序来来往往,但数据永远存在。

在模式设计中,无法摆脱列的长度。我想你是在问,中间层执行它们是否是一种好的做法。也许不是,但它们是数据库的关键。

通常,当您声明一组列是唯一的时,您会希望根据它进行查询,因此无论如何都应该对它进行索引。

是的,你的申请应该做适当的检查,但是如果一个错误通过了怎么办?如果您的数据库知道某个数据是唯一的,那么至少您知道您不会存储无效数据(或者不会“严重”存储无效数据,比如重复的数据是唯一的)。无论如何,你可以问一个相反的问题:你花了多少钱?

如果您想要有坏数据,那么去掉数据库中的唯一约束。我从70年代就开始研究数据库,查询或导入存储在数百个数据库中的数据。我从来没有在数据库中看到过好的数据,这些数据库的约束在应用程序级别设置得不正确。除了应用程序之外,还有许多事情会影响数据库(从其他系统导入、快速更新prod数据以修复从查询窗口运行的数据问题、其他应用程序等)。很多时候,应用程序被替换,约束丢失。

唯一约束和外来约束不仅加强了数据完整性,而且对性能有影响。如果不知道这些“非正式”常量,数据库优化器将对如何执行语句做出不可预知的决定。

在用户注册期间 没有这个,只有DB 我们将得到一个

这是我读过的最有趣的东西。你只是犯了个错误?这就是你真正需要的,对吗?听说过错误捕获吗?试着接电话吗?

它实际上是非常反作用,你的应用程序来“检查”。数据库无论如何都要检查约束,所以为什么要检查两次呢。应用程序应该只是插入行,好像它会没事。DB将检查唯一性并在出现故障时引发错误。。。你的应用程序应该捕捉到这个错误,并在现有的检查中执行任何操作。

对。只需捕获密钥冲突错误,密钥约束就可以为您完成这项工作,而不必首先产生额外检查的额外开销。