什么是数据库约束？
什么是数据库约束的明确定义？ 为什么约束对数据库很重要？ 什么是约束的types？
约束是数据库模式定义的一部分。
约束通常与表关联，并使用CREATE CONSTRAINT或CREATE ASSERTION SQL语句CREATE ASSERTION 。
他们定义数据库中的数据必须符合的某些属性。 他们可以应用于列，整个表，多个表或整个模式。 可靠的数据库系统可以确保约束始终保持不变（除了可能在事务内部，对于所谓的延迟约束）。
常见的约束是：
- 不为null – 列中的每个值都不能为NULL
- 指定列中的唯一值（一个或多个）对于表中的每一行必须是唯一的
- 主键 – 指定列中的值必须对表中的每一行都是唯一的，而不是NULL ; 通常数据库中的每个表都应该有一个主键 – 它用来标识单个logging
- 指定列中的外键值必须引用另一个表中的现有logging（通过主键或其他唯一约束 ）
- 检查 – 指定一个expression式，为了满足约束，它必须计算为true
要理解为什么我们需要约束，首先必须了解数据完整性的价值。
数据完整性是指数据的有效性。 你的数据是否有效？ 您的数据是否代表您devise的内容？
我问你什么奇怪的问题可能会想到，但遗憾的是，数据库往往充斥着垃圾数据，对其他表中的行的无效引用，已经过去了很长时间…和对业务逻辑没有任何意义的值的解决scheme。
所有这些垃圾并不是单靠减less性能，而是在应用程序逻辑下的一个定时炸弹，它最终将检索不被理解的数据。
约束条件是您在devise时创build的规则，可以保护您的数据不被损坏。 数据库解决scheme的核心孩子的长期生存是至关重要的。 没有限制，你的解决scheme肯定会随着时间和沉重的使用而衰减。
你必须承认，devise你的数据库devise只是你的解决scheme的诞生。 在此之后，它必须长期生存下去，并忍受最终用户（即客户端应用程序）的各种（奇怪的）行为。 但是，这个devise阶段的发展对于解决scheme的长期成功至关重要！ 尊重它，并付出所需的时间和注意力。
一个智者曾经说过： “数据必须自我保护！” 。 这是约束所做的。 这是保持数据库中的数据尽可能有效的规则。
这样做有很多方法，但基本上可以归结为：
- 外键约束可能是最常用的约束，并且确保只有在实际存在要引用的目标行时才允许对其他表的引用。 这也使得不可能通过删除被引用的行来创build死链接来破坏这种关系。
- 检查约束可以确保在特定列中只允许特定的值。 您可以创build一个约束，只允许在VARCHAR列中使用“黄色”或“蓝色”这个词。 所有其他值将产生一个错误。 获取使用检查约束的想法，检查AdventureWorks示例数据库中的
sys.check_constraints视图 - SQL Server中的规则只是可重用的检查约束（允许您从一个地方维护语法，并且更容易将约束部署到其他数据库）
正如我在这里暗示的那样，为数据库devise构build最好和最防御的约束方法需要一些彻底的考虑。 你首先需要知道上述不同约束types的可能性和局限性。 进一步阅读可能包括：
外键约束 – 微软
外键约束 – w3schools
检查约束
祝你好运！ ;）
约束只是数据的规则。 什么数据是有效的，什么是无效的可以使用约束来定义。 所以，数据的完整性可以保持。 以下是广泛使用的限制：
- 主键 ：唯一标识数据。 如果已经为某个列指定了这个约束，那么我们不能在该列中input重复的数据
- 检查 ：如
NOT NULL。 在这里，我们可以指定我们可以为特定列input哪些数据，以及哪些列不是预期的。 - 外键 ：对其他表的行的外键引用。 因此，从另一个表引用的数据始终可用于引用表。
约束规定了数据库中数据的有效值。 例如，你可以强制一个值不为空（一个NOT NULL约束），或者它作为另一个表（ FOREIGN KEY约束）中的唯一约束存在，或者它在表中是UNIQUE （ UNIQUE约束或者可能PRIMARY KEY约束取决于您的要求）。 更一般的约束可以使用CHECK约束来实现。
SQL Server 2008约束的MSDN文档可能是您最好的起始位置。
-
UNIQUE约束（其中PRIMARY KEY约束是一个变体）。 检查给定字段的所有值在整个表中是否唯一。 这是X轴约束（logging） -
CHECK约束（NOT NULL约束是其中的一个变体）。 检查某个条件是否适用于相同logging的字段上的expression式。 这是Y轴约束（字段） -
FOREIGN KEY约束。 检查在另一个表中的字段的值中find字段的值。 这是Z轴约束（表）。
约束可以用来强制数据的特定属性。 一个简单的例子是将int列限制为值[0-100000]。 这个介绍看起来不错。
数据库是概念（或商业）模型的计算机化的逻辑表示，由一组非正式的业务规则组成。 这些规则是用户理解的数据含义。 因为计算机只能理解forms表示，所以业务规则不能直接在数据库中表示。 它们必须映射到一个正式表示，一个逻辑模型，它由一组完整性约束组成。 这些约束 – 数据库模式 – 是业务规则数据库中的逻辑表示，因此是DBMS理解的数据含义。 因此，如果数据库pipe理系统没有意识到和/或不执行表示业务规则的全套约束条件，那么对数据的含义并不完全了解，因此不能保证（a）通过防止腐败， （b）从中得出的推论的完整性（即查询结果） – 这是另一种说DBMS最多不完整的方式。
注意：数据库pipe理系统“理解”的含义 – 完整性约束 – 与用户理解的含义 – 业务规则不完全相同 – 但是尽pipe如此，我们也获得了从数据中机械化逻辑推理的能力。
Fabian Pascal的“旧类错误”
SQL中主要约束有四种types
域约束：如果为新元组提供的属性值之一不是指定的属性域
关键约束：如果新元组中关键属性的值已经存在于关系中的另一个元组中
引用完整性：如果新元组中的外键值引用了引用关系中不存在的主键值
实体完整性：如果主键值在新元组中为null
约束条件是可以validation特定条件的条件。 与数据库相关的约束是域完整性，实体完整性，参照完整性，用户定义的完整性约束等。
