在SQLServer中,有3种不一样类型的约束。html
一、实体约束数据库
实体约束是关于行的,好比某一行出现的值就不容许出如今其余行,例如主键。编程
二、域约束ide
域约束是关于列的,对于全部行,某一列有那些约束,例如CHECK约束。post
三、参照完整性约束学习
若是某列的值必须与其余列的值匹配,那就意味着须要一个参照完整性约束,例如外键。this
在学习约束以前,首先来了解下为约束命名须要注意哪些地方。url
SQLServer在咱们不提供名称时,会自动建立名称,可是由系统自动建立的名称并非特别有用。spa
例如,系统生成的主键名称多是这样的:PK_Employees_145C0A3F。 code
PK表明主键(primary key),Employees表明在Employees表中,而剩下的“145C0A3F”部分是为了保证惟一性而随机生成的值。只有经过脚本建立才会获得这种值,若是是经过Managerment Studio建立表,那么就直接是PK_Employees。
对于系统自动生成的Check约束名称如:CK_Customers_22AA2996。CK表明这是一个Check约束,Customers表明是在Customers表中,后面的22AA2996仍是一个随机数。若是一个表中有多个Check约束,则命名可能以下:
CK_Customers_22AA2996
CK_Customers_25869641
CK_Customers_267ABA7A
若是你须要修改这些约束其中的一个,那么你很难分辨这些约束究竟是哪个。
所以,为了可以一眼看上去就知道这个约束是用来干什么的,咱们应该使用一种简单明了的短语来进行命名。
例如要确保某一列电话号码格式正确的约束,咱们可使用命名CK_Customers_PhoneNo这样的短语来命名。
总之命名要作到如下几点:
一、一致性
二、通俗易懂
三、知足以上两个条件的状况下简化名称。
主键是每行的惟一标识符,仅仅经过它就能准肯定位到一行,其中主键列在整个表中不能有重复,必须包含惟一的值(不能为NULL)。因为主键在关系数据库中的重要性,所以它是全部键和约束中最重要的。
下面来讲说主键的建立方式
一、在建立表的时候建立主键约束。
create table customer ( customerId int identity not null primary key, --建立主键约束 CustomerName nvarchar(30) not null );
怎么样,很是简单吧!
二、在已存在的表上建立主键约束
如今假设已经存在了一张表,可是尚未主键约束:
alter table person add constraint PK_Employee_Id --外键名称 primary key(personId) --personId 字段名
alter名称告诉SQLServer以下信息:
一、添加了一些内容到表中(也能够删除表中的某些内容)
二、添加了什么内容(一个约束)
三、对约束的命名(容许之后直接访问约束)
四、约束的类型(主键约束)
五、约束应用于哪一个列。
三、复合主键的建立
若是实在Management Studio中,建立复合主键,只须要按住Ctrl键,选中两个列,而后设置为主键就OK了,很是简单。下面主要讲述使用T-SQL建立复合主键的方法:
ALTER TABLE 表名 WITH NOCHECK ADD CONSTRAINT [PK_表名] PRIMARY KEY NONCLUSTERED ( [字段名1], [字段名2] )
在多对多联系中,经常会有一张表来描述其余两张表的关系,就以此读者和书为例子:
ALTER TABLE ReaderAndBook ADD CONSTRAINT [PK_ReaderAndBook] PRIMARY KEY NONCLUSTERED ( ReaderId, BookId )
外键既能确保数据完整性,也能表现表之间的关系。添加了外键以后,插入引用表的记录要么必须被引用表中被引用列的某条记录匹配,要么外键列的值必须设置为NULL。
外键和主键不同,每一个表中的外键数目不限制惟一性。在每一个表中,每一有-~253个外键。惟一的限制是一个列只能引用一个外键。一个列能够被多个外键引用。
一、建立表的时候建立外键
create table orders ( orderId int identity not null primary key, customerId int not null foreign key references customer(customerId) --约束类型-外键-引用表(列名) );
二、在已存在的表中添加一个外键
假设上面的代码去掉了添加外键行,那么能够书写代码以下:
alter table orders add constraint FK_Orders_CustomerId --添加约束 名称 foreign key (customerId) references customer(customerId) --外键约束,外键列名,被引用列名
刚添加的约束和以前添加的约束同样生效,若是某行引用customerId不存在,那么就不容许把该行添加到Orders表中。
三、级联动做
外键和其余类型键的一个重要区别是:外键是双向的,即不只是限制子表的值必须存在于父表中,还在每次对父表操做后检查子行(这样避免了孤行)。SQLServer的默认行为是在子行存在时“限制”父行被删除。然而,有时会自动删除任何依赖的记录,而不是防止删除被引用的记录。一样在更新记录时,可能但愿依赖的记录自动引用刚刚更新的记录。比较少见的状况是,你可能但愿将引用行改变为某个已知的状态。为此,能够选择将依赖行的值设置为NULL或者那个列的默认值。
这种进行自动删除和自动更新的过程称为级联。这种过程,特别是删除过程,能够通过几层的以来关系(一条记录依赖于另外一条记录,而这另外一条记录又依赖其余记录)。在SQLServer中实现级联动做须要作的就是修改外键语法-只须要在添加前面加上ON子句。例如:
alter table orders add constraint FK_Orders_CustomerId --添加约束 名称 foreign key (customerId) references customer(customerId) --外键约束,外键列名,被引用列名 on update no action --默认 修改时不级联更新子表 on delete cascade --删除时级联删除依赖行
当在进行级联删除时,若是一个表级联了另外一个表,而另外一个表又级联了其余表,这种级联会一直下去,不受限制,这实际上是级联的一个危险之处,很容易一个不当心删掉大量数据。
级联动做除了no action,cascade以外,还有set null和set default。后两个是在SQLServer2005中引入的,若是要兼容到SQLServer2000的话,要避免使用这两个级联动做。可是他们的才作是很是简单的:若是执行更新而改变了一个父行的值,那么子行的值将被设置为NULL,或者设置为该列的默认值(无论SET NULL仍是SET DEFAULT)。
四、外键其余方面的考虑
外键中的之只有相中可能的选择:
一、在列中填充与被引用表中的相应列相匹配的值。
经过定义引用列为NOT NULL,可使外键彻底是必须的(即用户添加数据时必须引用表中必须有相匹配的一行数据)。
二、不填充任何值,而使该值为NULL。
容许引用列有NULL值时,用户能够选择不提供值-即便在被引用表没有与NULL值匹配的行,仍是容许插入。
惟一约束与主键比较类似,共同点在于它们都要求表中指定的列(或者列的组合)上有一个惟一值,区别是惟一约束没有被看做表中记录的惟一标识符(即便你能够按这样的方式使用也有效),并且能够有多个惟一约束(而在每一个表中只能有一个主键)。
一旦创建了惟一约束,那么指定列中的每一个值必须是惟一的。若是更新或者插入一条记录在带惟一约束的列上有已经存在的值的记录,SQLServer将抛出错误,拒绝这个记录。
和主键不一样,惟一约束不会自动防止设置一个NULL值,是否容许为NULL由表中相应列的NULL选项的设置决定,但即便确实容许NULL值,一张表中也只可以插入一个NULL值(若是容许多个,那就不叫惟一了)。
在已存在的表上建立惟一约束:
alter table Account add constraint AK_AccountName --约束名 unique (Account_Name) -- 列名
AK表明替换键(Alternate Key),惟一约束也叫替换键。
主键和惟一约束的区别:
CHECK约束约束能够和一个列关联,也能够和一个表关联,由于它们能够检查一个列的值相对于另一个列的值,只要这些列都在同一个表中以及值是在更新或者插入的同一行中。CHECK约束还能够用于检查列值组合是否知足某一个标准。
能够像使用where子句同样的规则来定义CHECK约束。CHECK约束条件的示例以下:
目标 | SQL |
限制Month列为合适的数字 | BETWEEN 1 AND 12 |
正确的SSN格式 | LIKE'[0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9][0-9][0-9]' |
限制为一个快递公司的特定列表 | IN('UPS','Fed Ex',EMS') |
价格必须为正数 | UnitPrice >= 0 |
引用同一行中的另一列 | ShipDate >= OrderDate |
上面给出的列表只是一小部分,而条件实际上市无限多的。几乎全部能够放到where子句的条件均可以放到该约束中。并且和其余选择(规则和触发器)相比,CHECK约束执行速度更快。
在已存在的表中添加一个CHECK约束:
alter table Account add constraint CN_AccountAge check (Account_Age > 18); -- 插入年龄必须大于18
若是此时视图添加一条不知足的记录,将报以下错误:
insert into Account values (22,'洪',17)
消息 547,级别 16,状态 0,第 1 行 INSERT 语句与 CHECK 约束"CN_AccountAge"冲突。该冲突发生于数据库"Nx",表"dbo.Account", column 'Account_Age'。 语句已终止。
和全部约束同样,DEFAULT约束也是表定义的一个组成部分,它定义了当插入的新行对于定义了默认约束的列未提供相应数据时该怎么办。能够定义它为一个字面值(例如,设置默认薪水为0,或者设置字符串列为"UNKNOWN"),或者某个系统值(getdate())。
对于DEFAULT约束,要了解如下几个特性:
一、默认值只在insert语句中使用-在update语句和delete语句中被忽略。
二、若是在insert语句中提供了任意值,那就不使用默认值。
三、若是没有提供值,那么老是使用默认值。
值得注意的是,update命令的规则由一个例外,若是显示说明使用默认值就是例外。能够经过使用关键字DEFAULT表示更新的值设置为默认值。
5.1在建立表时定义DEFAULT约束:
create table person ( person_id int identity not null primary key, person_name nvarchar(30) not null default '无名氏', person_age int not null )
在执行语句后:
insert into person (person_age) values(24)
表中被插入一条记录以下:
5.2在已存在的表上添加DEFAULT约束:
alter table person add constraint CN_DefaultName default '无名氏' for person_name
有时咱们想暂时或永久地消除约束。可是SQL Server并无提供删除约束的方法。SQL Server只容许禁用外键约束或CHECK约束,而同时保持约束的完整性。
禁用一个数据完整性规则一般是由于已经有无效数据了。这样的数据一般分为如下两类:
一、在建立约束时已经在数据库中的数据
二、在约束建立之后但愿添加的数据
SQL Server容许禁用完整性检查一段时间来对例外的无效数据做处理,而后再从新启用完整性(不是物理删除数据完整性约束)。
注意:不能禁用主键约束或者惟一约束
6.一、在建立约束时,忽略检查以前的不知足数据
要添加一个约束,可是有不该用到已存在的数据中,能够再执行Alter Table语句添加约束时使用WITH NOCHECK选项。
按照上面建立Check约束的方法,已经Alter Table时,表中自己已经存在不符合的数据,那么Alter Table操做将被SQL Server拒绝执行。除非已经存在的全部数据都知足CHECK约束的条件,不然SQL Server不会执行建立约束的命令。要解决这个问题,咱们能够添加WITH NOCHECK。
咱们先新建一个表只有3个字段的表,Id、姓名、年龄,并在里面插入一条不知足要求的数据:
insert into Account values (23,'洪',17)
而后执行添加约束命令:
alter table Account add constraint CN_AccountAge18 check (Account_Age > 18); -- 插入年龄必须大于18
SQL Server报一下错误:
消息 547,级别 16,状态 0,第 1 行 ALTER TABLE 语句与 CHECK 约束"CN_AccountAge18"冲突。该冲突发生于数据库"Nx",表"dbo.Account", column 'Account_Age'。
这时候咱们换一种方式去执行:
alter table Account WITH NOCHECK add constraint CN_AccountAge18 check (Account_Age > 18); -- 插入年龄必须大于18
以上代码就可以成功执行,而且只有之后添加的数据具有约束,以前添加的不符合条件的数据记录依然存在。
6.2临时禁用已存在的约束
当咱们须要从另外一数据库中导入数据到表中,而表中已创建了约束的时候,可能会存在一些数据和规则不匹配。固然有一个解决方式是先删除约束,添加须要的数据,而后WITH NOCHECK在添加回去。可是这样作太麻烦了。咱们不须要这么作。咱们能够采用名为NOCHECK的选项来运行ALTER语句,这样就可以取消须要的约束。
先来看看上节中建立的这个约束:
alter table Account add constraint CN_AccountAge18 check (Account_Age > 18); -- 插入年龄必须大于18
要取消以上约束能够这样来:
Alter Table Account NOCHECK constraint CN_AccountAge18
执行命令:
insert into Account values (25,'取消了约束',17)
执行成功,成功添加了一行数据。
留意到又可以向表中插入格式不匹配的数据了。
这里要说明下,以下知道一个约束是不是启用仍是禁用呢?sp_helpconstraint命令,当咱们执行sp_helpconstraint的时候,会有一列status_enabled显示该约束的启用状态:
sp_helpconstraint Account
留意到status_enabled列为Disabled说明是禁用的意思。
当要启用约束时,只须要用将语句中的NO CHECK替换为CHECK就能够了:
Alter Table Account CHECK constraint CN_AccountAge18
执行以后,约束又启用了:再来sp_helpconstraint看下:
留意到status_enabled列变成了Enabled。
status_enabled的两种状态以下:
Enabled:启用;
Disabled:禁用;
规则和默认值的应用要早于CHECK和DEFAULT约束。他们是较老的SQL Server备用约束的一部分,固然也不是没有优势。自7.0版本以后,MicroSoft列出规则和默认值只是为了向后兼容,而不许备在之后继续支持这个特性。所以对于生成新代码时,应该使用约束。
规则、默认值与约束的本质区别是:约束是一个表的特征,自己没有存在形式,而规则和默认值是表和自身的实际对象,自己存在。约束是在表定义中定义的,而规则和默认值是单独定义,而后"绑定到"表上。
规则和默认值的独立对象特性使得它们能够在重用时不用从新定义。实际上,规则和默认值不限于被绑定到表上,它们也能够绑定到数据类型上。
7.1规则
规则和CHECK约束很是类似。它们之间的惟一区别是规则每次只能做用于一个列。能够将同一规则分别绑定到一个表中的多个列,可是规则分别做用于每一个列,根本不会意识到其余列的存在。像QtyShipped
<= QtyOrdered这样的约束不适用于规则(它引用多个列),而LIKE([0-9][0-9][0-9])这样的定义适用于规则。
定义规则:
下面定义一个规则,这样就能够首先看到区别所在:
CREATE RULE Age18Rule AS @Age > 18
这里比较的是一个变量,无论被检查的列是什么值,这个值将用于替换@Age。所以在这个示例中,规则所绑定的任何列的值都必须大于18。
到目前为止,只是建立了一个规则,但这个规则还没对任何表的任何列起做用,要激活这个规则须要使用一个存储过程:sp_bindrule。
将规则Age18绑定到表person的person_age列:
EXEC sp_bindrule 'Age18Rule','person.person_age';
此时,若是咱们执行不知足规则的插入操做:
insert into person values ('绑定规则',17)
将返回以下报错信息:
消息 513,级别 16,状态 0,第 1 行 列的插入或更新与先前的 CREATE RULE 语句所指定的规则发生冲突。该语句已终止。冲突发生于数据库 'Nx',表 'dbo.person',列 'person_age'。 语句已终止。
很明显,规则已经生效。
要特别注意的是,在绑定以前,规则与任何表,任何列都没有关系,所以在绑定的时候,第二个参数要加.指定表名与列名(tablename.column)。
解除绑定规则:
当咱们须要在一个列上解除绑定规则的时候,只要执行sp_unbindrule
删除刚才绑定的规则:
EXEC sp_unbindrule 'person.person_age';
这时候,执行刚才的插入操做,就不会报错了。
删除规则:
若是但愿将规则从数据库中完全删除,那么能够在表中使用很是熟悉的DROP语法。
DROP RULE <rule name>
如删除刚才建立的那条规则:
DROP RULE Age18Rule
7.2默认值
默认值相似于DEFAULT。实际上默认值-DEFAULT约束的关系与规则-CHECK约束的关系差很少。区别在于它们被追加到表中的方式和对用户自定义数据类型的默认值(是对象,而不是约束)支持。
定义默认值的语法和定义规则相似:
CREATE DEFAULT <default_name> AS <default value>
建立默认值:
所以,假设要为Age定义一个值为0的默认值:
CREATE DEFAULT AgeDefault AS 0
绑定默认值:
一样,若是不绑定到一个对象上,则默认值是不起做用的。要绑定的话,使用存储过程sp_bindefault。
EXEC sp_bindefault 'AgeDefault','person.person_age';
要从表中解决默认值的绑定,使用sp_unbindefault:
sp_unbindefault 'person.person_age';
删除默认值:
若是要从数据库中完全删除一个默认值,则可使用DROP语法,与删除规则相同:
DROP DEFAULT AgeDefault
7.3肯定哪一个表和数据类型使用给定的规则或默认值
若是但愿删除或者修改规则或默认值。那么您能够先看看哪些表和数据类型在使用它们。SQL Server仍是采用系统存储过程解决这个问题。这个存储过程是sp_depends。其语法以下所示:
EXEC sp_depends <object name>
sp_depends提供了依赖于你所查询对象的全部对象列表。
触发器也可以用于实现数据完整性,这个内容比较多,新建一篇文章叙述。
通过以上的学习,对于数据完整性,你会发现有不少种能够选择,那么如何挑选合适的约束呢?
限制 | 优势 | 缺点 |
约束 | 快速 能够引用其余列 在命令执行前发生 遵循ANSI标准 |
必须对每一个表从新定义 不能引用其余表 不能绑定到数据类型 |
规则 | 独立的对象 可重用 能够绑定到数据类型 命令执行前发生 |
稍慢 不能跨列使用 不能引用其余表 实际上只用于向后兼容 |
默认值 | 很是灵活 能够引用其余列或其余表 能够经过.NET引用SQL Server以外的其余信息 |
在命令执行以后发生 系统开销很大 |
若是要实现更健壮的逻辑模型以及普遍使用用户自定义数据类型,则通常使用规则和默认值。在这种状况下规则和默认值能够提供不少功能,容易管理,而不用太多的编程开销。
只有在不能选择约束时使用触发器。和约束同样,他们被附加到表中,并且必须对建立的每一个表从新定义。好的方面是触发器几乎能够作数据完整性方面的任何操做。实际上再没有出现外键时,他们常被用做外键的替代品。
而在其余状况下,应将约束做为数据完整性解决方案的选择。它们执行速度快,并且不难建立。他们的缺点是功能有限(除了外键约束,都不能引用其余表),并且对于通用约束逻辑来讲,须要一次次地从新定义。