数据库约束查找的约束_数据库约束的好处，成本和文档

数据库约束查找的约束

Constraints exist as a way to enforce or document rules within the database. How do they affect performance, and what are the benefits of using them?

约束是在数据库中强制执行或记录规则的一种方式。它们如何影响性能？使用它们有什么好处？

介绍 (Introduction)

There are a variety of constraints that can be implemented in a SQL Server database that can provide a variety of new functionality. Some are so familiar that we forget their presence, such as NULL constraints, while others may not be used as often, such as check constraints or default constraints.

在SQL Server数据库中可以实现各种约束，这些约束可以提供各种新功能。有些非常熟悉，以至于我们忘记了它们的存在，例如NULL约束，而有些则可能不那么常用，例如检查约束或默认约束。

This is an opportunity to dive into each type of constraint, and after introducing their purpose and usage, dive into their storage, performance, and notes about their optimal use, as well as pitfalls. Please note that all demos were created and tested in SQL Server 2016 RC1.

这是深入研究每种约束类型的机会，并在介绍了它们的用途和用途之后，深入研究了它们的存储，性能以及关于它们的最佳使用以及陷阱的注意事项。请注意，所有演示均已在SQL Server 2016 RC1中创建和测试。

目的 (Purpose)

Constraints may be used for a variety of purposes. The following is a short list of what I consider the most common reasons that constraints are created:

约束可以用于多种目的。以下是我认为创建约束的最常见原因的简短列表：

Prevent bad data from being entered into tables of interest. 防止将不良数据输入到感兴趣的表中。
Enforce business logic at the database-level. 在数据库级别实施业务逻辑。
Documentation of important database rules. 重要数据库规则的文档。
Enforce relational integrity between any number of tables. 增强任意数量表之间的关系完整性。
Improve database performance. 提高数据库性能。
Enforce uniqueness. 增强唯一性。

There are others, of course, but the reasons for using constraints are quite varied, and can be a helpful tool for database administrators and developers alike. Typically, it is recommended to use constraints over more complex, procedural logic-enforcement, such as triggers, rules, stored procedures, or jobs.

当然，还有其他原因，但是使用约束的原因千差万别，对于数据库管理员和开发人员而言，它都是有用的工具。通常，建议对更复杂的过程逻辑执行使用约束，例如触发器，规则，存储过程或作业。

Let’s review one-at-a-time each type of constraint and some examples of their usage.

让我们一次查看每种约束类型及其用法的一些示例。

非空约束 (NOT NULL constraints)

This is so common that we may forget that a column that does not allow NULLs is technically in possession of a NOT NULL constraint. Its function is straightforward: a column with this constraint will not allow a NULL to be entered, and will throw an error when anyone attempts to enter a NULL into a column that doesn’t allow NULLs.

这是如此常见，以至于我们可能忘记了不允许NULL的列在技术上拥有NOT NULL约束。它的功能很简单：具有此约束的列将不允许输入NULL，并且当任何人试图在不允许NULL的列中输入NULL时都会抛出错误。

NULL may be defined at the time a table is defined, such as like this:

可以在定义表时定义NULL，例如：


CREATE TABLE dbo.NullDemo
(   Null_Id INT NOT NULL,Null_Data VARCHAR(50) NULL,Not_Null_Data VARCHAR(50) NOT NULL);

The syntax is simple, and in this table, Null_Id and Not_Null_Data will not allow any NULLs to be entered into either. Null_Data, on the other hand, will allow NULL, in addition to standard string values. When creating a table, you can choose to not specify NULL or NOT NULL, and if you do, the column will default to being NULLable. Since NOT NULL is an explicit constraint, the default setting for any column is to allow NULLs.

语法很简单，在此表中， Null_Id和Not_Null_Data不允许将任何NULL输入其中一个。另一方面， Null_Data除了标准字符串值外，还将允许NULL。创建表时，可以选择不指定NULL或NOT NULL，如果这样做，则该列将默认为NULLable。由于NOT NULL是显式约束，因此任何列的默认设置是允许NULL。

Using this table, let’s insert a few rows into it:

使用此表，让我们在其中插入几行：


INSERT INTO dbo.NullDemo(Null_Id, Null_Data, Not_Null_Data)
SELECT1, 'Stegosaurus', 'Spiky';
INSERT INTO dbo.NullDemo(Null_Id, Null_Data, Not_Null_Data)
SELECT2, 'Tyrannosaurus', 'Huge';

Both of these inserts succeed without incident, adding two dinosaurs into our demo table.

这两个插入都成功了，没有发生意外，将两个恐龙添加到了我们的演示表中。


INSERT INTO dbo.NullDemo(Null_Id, Null_Data, Not_Null_Data)
SELECT3, NULL, 'Long Neck';

This also works without a problem. Inserting a NULL is OK since we explicitly defined Null_Data to allow NULLs.

这也没有问题。插入NULL是可以的，因为我们明确定义了Null_Data以允许NULL。


INSERT INTO dbo.NullDemo(Null_Id, Null_Data, Not_Null_Data)
SELECT4, 'Pterodactylus ', NULL;

Our poor dino-flyer never makes it into the database as we tried to insert a NULL into the last column, Not_Null_Data, which we applied the NOT NULL constraint to. The result is the expected error:

当我们试图在最后一列Not_Null_Data中插入NULL时，我们可怜的dino-flyer从未进入数据库，因为我们将NOT NULL约束应用于了该列。结果是预期的错误：

Msg 515, Level 16, State 2, Line 27
Cannot insert the value NULL into column ‘Not_Null_Data’, table ‘AdventureWorks2014.dbo.NullDemo’; column does not allow nulls. INSERT fails.
The statement has been terminated.

信息515，第16级，州2，第27行
无法将值NULL插入表'AdventureWorks2014.dbo.NullDemo'的'Not_Null_Data'列中；列不允许为空。插入失败。
该语句已终止。

NOT NULL is exceptionally useful when we have a table with columns that are critical to the definition of that data structure. For example, an account without a name would be potentially meaningless, whereas an employee with no start date would cause us to scratch our heads and ask why no one entered it in the first place.

当我们有一个表的列对于该数据结构的定义至关重要时，NOT NULL异常有用。例如，没有名称的帐户可能毫无意义，而没有开始日期的员工会导致我们挠头，问为什么没有人首先输入。

NOT NULL corrects mistakes by the user as well as mistakes by a software or database developer. If a column is required, then we want to ensure that it is always entered, no matter what. The application should tell a user that they need to enter a required field, returning a friendly message if they forget. In the event that the application somehow allows a NULL where one does not belong, then an error would be returned that the developers could easily troubleshoot and fix. This scenario is preferable to allowing data to be created with critical missing elements.

NOT NULL纠正用户的错误以及软件或数据库开发人员的错误。如果需要一列，那么我们要确保始终输入该列，无论如何。应用程序应告知用户他们需要输入必填字段，如果忘记了，则会返回友好的消息。如果应用程序以某种方式允许一个不属于其中的NULL，则将返回错误，开发人员可以轻松地进行故障排除和修复。此方案比允许使用严重缺失的元素创建数据更好。

There are potentially dangerous or inappropriate uses for NOT NULL. While we tend to prefer not having NULLs to deal with in our code, forcing arbitrary values into our data can be dangerous. A NOT NULL string that defaults to a blank is relatively harmless, but what about a NOT NULL date or a NOT NULL integer? How many times have we run into a date column that was peppered with “1/1/1900” within its data? Or the integer that uses “-1” to fill in the blanks? This data can become confusing as the columns appear to have valid values, when in fact they contain dummy data. Special application or database code needs to check for these values and act appropriately when they exist. In addition, what happen if a user deliberately enters a value that matches a dummy value? Will the application disallow this? Will the database consider their entry irrelevant and the same as taking some default instead? What if your great grandfather was actually born on 1/1/1900? As of the writing of this article, there are people older than 116 years old and have birthdays that fall around this oft-used dummy date. Improbable — sure, but if I was 116 years old and got an error while signing up for Snapchat, I’d be pretty pissed off