SQL的主键和外键的作用：
外键取值规则：空值或参照的主键值。
(1)插入非空值时，如果主键表中没有这个值，则不能插入。
(2)更新时，不能改为主键表中没有的值。
(3)删除主键表记录时，你可以在建外键时选定外键记录一起级联删除还是拒绝删除。
(4)更新主键记录时，同样有级联更新和拒绝执行的选择。
简而言之，SQL的主键和外键就是起约束作用。
定义主键和外键主要是为了维护关系数据库的完整性，总结一下：
一、主键是能确定一条记录的唯一标识，比如，一条记录包括身份正号，姓名，年龄。身份证号是唯一能确定你这个人的，其他都可能有重复，所以，身份证号是主键。
外键用于与另一张表的关联。是能确定另一张表记录的字段，用于保持数据的一致性。比如，A表中的一个字段，是B表的主键，那他就可以是A表的外键。
二、主键、外键和索引的区别
定义：
主键--唯一标识一条记录，不能有重复的，不允许为空
外键--表的外键是另一表的主键, 外键可以有重复的, 可以是空值
索引--该字段没有重复值，但可以有一个空值
作用：
主键--用来保证数据完整性
外键--用来和其他表建立联系用的
索引--是提高查询排序的速度
个数：
主键--主键只能有一个
外键--一个表可以有多个外键
索引--一个表可以有多个唯一索引
创建SQL的主键和外键约束的方法：
create table Student --建表格式:create table 自定义的表名
( --字段名一般为有一定意义的英文
StudentName nvarchar(15), -- 格式：字段名类型()括号里面的是允许输入的长度
StudentAge int, --int型的后面不需要接长度
StudentSex nvarchar(2) --最后一个字段后面不要逗号
)
--在创建表时就可以对字段加上约束:
create table Student
(
StudentNo int PRIMARY KEY IDENTITY(1,1), --加主键约束,还有标识列属性（两者构成实体完整性）
StudentName nvarchar(15) not null, --加非空约束,不加"not null" 默认为：可以为空
StudentSchool text(20) FOREIGN KEY REFERENCES SchoolTable(SchoolName), --加外键约束,格式:FOREIGN KEY REFERENCES 关联的表名(字段名)
StudentAge int DEFAULT ((0)), --加默认值约束
StudentSex nvarchar(2) CHECK(StudentSex=N'男' or StudentSex=N'女') --加检查约束,格式:check (条件表达式)
)
--如果在表创建好了以后再加约束，则格式分别为：
-- 主键:
alter table 表名
add constraint PK_字段名--"PK"为主键的缩写，字段名为要在其上创建主键的字段名,'PK_字段名'就为约束名
primary key (字段名) --字段名同上
--唯一约束:
alter table 表名
add constraint UQ_字段名
unique (字段名)
--外键约束：
alter table 表名
add constraint FK_字段名--"FK"为外键的缩写
foreign key (字段名) references 关联的表名(关联的字段名) --注意'关联的表名'和'关联的字段名'
alter table 表A add constraint FK_B foreign key (ticket_no) references 表B(ticket_no)
alter table 表A add constraint FK_C foreign key (person_no) references 表C(person_no)
alter table 成绩表 add constraint FK_StudentNo foreign key (StudentNo) references Student(StudentNo)
ON UPDATE CASCADE ON DELETE CASCADE
级联更新，级联删除，这样在删除主表Student时，成绩表中该学生的所有成绩都会删除。
--检查约束:
alter table 表名
add constraint CK_字段名
check (条件表达式) --条件表达式中的条件用关系运算符连接
--默认值约束:
alter table 表名
add constraint DF_字段名
default '默认值' for 字段名--其中的'默认值'为你想要默认的值，注意'for'
--删除创建的约束:
alter table 表名
drop constraint 约束名--约束名为你前面创建的如：PK_字段这样的约束名
--注意：如果约束是在创建表的时候创建的，则不能用命令删除
--只能在'企业管理器'里面删除
-- 获取SqlServer中表结构
SELECT syscolumns.name,systypes.name,syscolumns.isnullable,
syscolumns.length
FROM syscolumns,systypes
WHERE syscolumns.xusertype = systypes.xusertype
AND syscolumns.id = OBJECT_ID('Student')
-- 单独查询表递增字段
SELECT [name] FROM syscolumns WHERE
id = OBJECT_ID(N'Student') AND COLUMNPROPERTY(id,name,'IsIdentity')=1
-- 获取表主外键约束
EXEC sp_helpconstraint 'StuResults'
-- 查询表主键外键信息
SELECT sysobjects.id objectId,OBJECT_NAME(sysobjects.parent_obj) tableName,
sysobjects.name constraintName, sysobjects.xtype AS constraintType,
syscolumns.name AS columnName
FROM sysobjects INNER JOIN sysconstraints
ON sysobjects.xtype in('C', 'F', 'PK', 'UQ', 'D')
AND sysobjects.id = sysconstraints.constid
LEFT OUTER JOIN syscolumns ON sysconstraints.id = syscolumns.id
WHERE OBJECT_NAME(sysobjects.parent_obj)='StuResults'
1.约束定义了必须遵循的的用户维护数据一致性和正确性的规则，是强制实现数 据完整性的主要途径。
主键约束(primary key)
唯一性约束(unique)
检查约束(check) 条件的构造
范围 字段 in（集合）
字段 between........and
字段 >=value1 and 字段<=value1
逻辑运算符: and
or
not
困难所在：要求字段符合一定的模式或者叫做模式匹配
[NOT]LIKE(模糊查询也用到它)
check(stuName like 'li_')
like的使用最重要的是要掌握通配符
重点在于patten的构造
1.普通字符
2.通配符：% 代表零个或更多字符的任意字符串
_代表一个字符
[]代表指定范围[a-f]或集合([abcdef])中的任何单个字符
[^]不属于指定范围([a-f])或集合([abcdef])中的任何单个字符
例如： check ( stuName LIKE ' [% ]')
check( stuName LIKE ' 张[%]')
check( stuAge LIKE ' [18-20] ' AND
NOT LIKE ' [^19] '
check( stuAge IN(18-19))
年龄在18-20，但不等于19
3.转义字符
默认约束
外键约束(参照约束)
约束可以在以下两个层次上实施：
列级：用户定义的约束只对表中的一列起作用。
表级：用户定义的约束对表中的多列起作用。
2.约束的创建
（1）.创建表的同时，建立约束，使用CREATE TABLE语句创建约束
CREATE TABLE 表名
(
列名 列的数据类型
CONSTRAINT 约束名 约束的类型
......n
)
（ 2）.表创建后，通过修改来实现约束的添加，使用ALTER TABLE命令
ALTER TABLE 表名
WITH CHECK | WITH NOCHECK
ADD CONSTRAINT 约束名 约束的类型
3.主键约束（PRIMARY KEY）
主键用于唯一地标识表中的每一条记录
可以定义一列或多列为主键
主键列上没有任何两行具有相同值（即重复值）
主键列上也不能为空值
4.唯一性约束（UNIQUE）
唯一性约束用来限制不受主键约束的列上的数据的唯一性，
即表中任意两行在 指定列上都不允许有相同的值。
一个表上可以放置多个唯一性约束
唯一性约束和主键约束的区别：
（1）.唯一性约束允许在该列上存在NULL值，而主键约束的限制更为严格，不但不允许有重复，而且也不允许有空值。
（2）.在创建唯一性约束和主键约束时可以创建聚集索引和非聚集索引，但在 默认情况下主键约束产生聚集索引，而唯一性约束产生非聚集索引
5.检查约束（CHECK）
检查约束用来指定某列的可取值的范围。
它通过限制输入到列中的值来强制域的完整性。
6.默认约束（DEFAULT）
默认约束用于给表中的指定列赋予一个常量值（默认值），当向该表插入数据 时如果用户没有明确给出该列的值，SQL Server会自动为该列输入默认值。每 列只能有一个默认约束。
add constraint 名字 default (表达式 Null) for 默认约束的字段名
7.外键约束（FOREIGN KEY）
外键约束用于与其他表（称为参照表）中的列（称为参照列）建立连接。
将参照表中的主键所在列或具有唯一性约束的列包含在另一个表中，这些列就 构成了另一个表的外键。
当参照表中的参照列更新后，外键列也会自动更新， 从而保证两个表之间的 一致性关系。
注意：(1).将“强制外键约束”或"强制用于复制”设置为“是”，能确保任何数据添加、修改或删除操作都不会违背外键关系
(2).将“更新规则”或"删除规则”设置为“无操作”，拒绝更新或删除主键表
将“更新规则”或"删除规则”设置为“层叠”，级联更新或删除从表中相应的所有行
将“更新规则”或"删除规则”设置为“设置空”，将外键表中相对应的外 键值设置为空值NULL
将“更新规则”或"删除规则”设置为“设置默认值”，如果外键表的所有外键列均已定义默 认值，则该列设置为默认值
主键与外键
一、什么是主键、外键：
关系型数据库中的一条记录中有若干个属性，若其中 某一个属性组(注意是组)能唯一标识一条记录 ，该属性组就可以成为一个主键比如
学生表(学号，姓名，性别，班级)
其中每个学生的学号是唯一的，学号就是一个主键
课程表(课程编号,课程名,学分)
其中课程编号是唯一的,课程编号就是一个主键
成绩表(学号,课程号,成绩)
成绩表中单一一个属性无法唯一标识一条记录，学号和课程号的组合才可以唯一标识一条记录，所以 学号和课程号的属性组是一个主键
成绩表中的学号不是成绩表的主键，但它和学生表中的学号相对应，并且学生表中的学号是学生表的主键，则称成绩表中的学号是学生表的外键
同理 成绩表中的课程号是课程表的外键
定义主键和外键主要是为了维护关系数据库的完整性，总结一下：
主键是能确定一条记录的唯一标识，比如，一条记录包括身份正号，姓名，年龄。身份证号是唯一能确定你这个人的，其他都可能有重复，所以，身份证号是主键。
外键用于与另一张表的关联。是能确定另一张表记录的字段，用于保持数据的一致性。比如，A表中的一个字段，是B表的主键，那他就可以是A表的外键。
主键、外键和索引的区别？
|
| 主键 | 外键 | 索引 |
| 定义： | 唯一标识一条记录，不能有重复的，不允许为空 | 表的外键是另一表的主键, 外键可以有重复的, 可以是空值 | 该字段没有重复值，但可以有一个空值 |
| 作用： | 用来保证数据完整性 | 用来和其他表建立联系用的 | 是提高查询排序的速度 |
| 个数： | 主键只能有一个 | 一个表可以有多个外键 | 一个表可以有多个惟一索引 |
聚集索引和非聚集索引的区别？
聚集索引一定是唯一索引。但唯一索引不一定是聚集索引。
聚集索引，在索引页里直接存放数据，而非聚集索引在索引页里存放的是索引，这些索引指向专门的数据页的数据。
三、数据库中主键和外键的设计原则
主键和外键是把多个表组织为一个有效的关系数据库的粘合剂。主键和外键的设计对物理数据库的性能和可用性都有着决定性的影响。
必须将数据库模式从理论上的逻辑设计转换为实际的物理设计。而主键和外键的结构是这个设计过程的症结所在。一旦将所设计的数据库用于了生产环境，就很难对这些键进行修改，所以在开发阶段就设计好主键和外键就是非常必要和值得的。
主键：
关系数据库依赖于主键---它是数据库物理模式的基石。主键在物理层面上只有两个用途：
1. 惟一地标识一行。
2. 作为一个可以被外键有效引用的对象。
基于以上这两个用途，下面给出了我在设计物理层面的主键时所遵循的一些原则：
1. 主键应当是对用户没有意义的。如果用户看到了一个表示多对多关系的连接表中的数据，并抱怨它没有什么用处，那就证明它的主键设计地很好。
2. 主键应该是单列的，以便提高连接和筛选操作的效率。
注：使用复合键的人通常有两个理由为自己开脱，而这两个理由都是错误的。其一是主键应当具有实际意义，然而，让主键具有意义只不过是给人为地破坏数据库提供了方便。其二是利用这种方法可以在描述多对多关系的连接表中使用两个外部键来作为主键，我也反对这种做法，理由是：复合主键常常导致不良的外键，即当连接表成为另一个从表的主表，而依据上面的第二种方法成为这个表主键的一部分，然，这个表又有可能再成为其它从表的主表，其主键又有可能成了其它从表主键的一部分，如此传递下去，越靠后的从表，其主键将会包含越多的列了。
3. 永远也不要更新主键。实际上，因为主键除了惟一地标识一行之外，再没有其他的用途了，所以也就没有理由去对它更新。如果主键需要更新，则说明主键应对用户无意义的原则被违反了。
注：这项原则对于那些经常需要在数据转换或多数据库合并时进行数据整理的数据并不适用。
4. 主键不应包含动态变化的数据，如时间戳、创建时间列、修改时间列等。
5. 主键应当有计算机自动生成。如果由人来对主键的创建进行干预，就会使它带有除了惟一标识一行以外的意义。一旦越过这个界限，就可能产生认为修改主键的动机，这样，这种系统用来链接记录行、管理记录行的关键手段就会落入不了解数据库设计的人的手中。
四、数据库主键选取策略
我们在建立数据库的时候，需要为每张表指定一个主键，所谓主键就是能够唯一标识表中某一行的属性或属性组，一个表只能有一个主键，但可以有多个候选索引。因为主键可以唯一标识某一行记录，所以可以确保执行数据更新、删除的时候不会出现张冠李戴的错误。当然，其它字段可以辅助我们在执行这些操作时消除共享冲突，不过就不在这里讨论了。主键除了上述作用外，常常与外键构成参照完整性约束，防止出现数据不一致。所以数据库在设计时，主键起到了很重要的作用。
常见的数据库主键选取方式有：
- 自动增长字段
- 手动增长字段
- UniqueIdentifier
- “COMB（Combine）”类型
1自动增长型字段
很多数据库设计者喜欢使用自动增长型字段，因为它使用简单。自动增长型字段允许我们在向数据库添加数据时，不考虑主键的取值，记录插入后，数据库系统会自动为其分配一个值，确保绝对不会出现重复。如果使用SQL Server数据库的话，我们还可以在记录插入后使用@@IDENTITY全局变量获取系统分配的主键键值。
尽管自动增长型字段会省掉我们很多繁琐的工作，但使用它也存在潜在的问题，那就是在数据缓冲模式下，很难预先填写主键与外键的值。假设有两张表：
Order(OrderID, OrderDate)
OrderDetial(OrderID, LineNum, ProductID, Price)
Order表中的OrderID是自动增长型的字段。现在需要我们录入一张订单，包括在Order表中插入一条记录以及在OrderDetail表中插入若干条记录。因为Order表中的OrderID是自动增长型的字段，那么我们在记录正式插入到数据库之前无法事先得知它的取值，只有在更新后才能知道数据库为它分配的是什么值。这会造成以下矛盾发生：
首先，为了能在OrderDetail的OrderID字段中添入正确的值，必须先更新Order表以获取到系统为其分配的OrderID值，然后再用这个OrderID填充OrderDetail表。最后更新OderDetail表。但是，为了确保数据的一致性，Order与OrderDetail在更新时必须在事务保护下同时进行，即确保两表同时更行成功。显然它们是相互矛盾的。
除此之外，当我们需要在多个数据库间进行数据的复制时（SQL Server的数据分发、订阅机制允许我们进行库间的数据复制操作），自动增长型字段可能造成数据合并时的主键冲突。设想一个数据库中的Order表向另一个库中的Order表复制数据库时，OrderID到底该不该自动增长呢？
ADO.NET允许我们在DataSet中将某一个字段设置为自动增长型字段，但千万记住，这个自动增长字段仅仅是个占位符而已，当数据库进行更新时，数据库生成的值会自动取代ADO.NET分配的值。所以为了防止用户产生误解，建议大家将ADO.NET中的自动增长初始值以及增量都设置成-1。此外，在ADO.NET中，我们可以为两张表建立DataRelation，这样存在级联关系的两张表更新时，一张表更新后另外一张表对应键的值也会自动发生变化，这会大大减少了我们对存在级联关系的两表间更新时自动增长型字段带来的麻烦。
2手动增长型字段
既然自动增长型字段会带来如此的麻烦，我们不妨考虑使用手动增长型的字段，也就是说主键的值需要自己维护，通常情况下需要建立一张单独的表存储当前主键键值。还用上面的例子来说，这次我们新建一张表叫IntKey，包含两个字段，KeyName以及KeyValue。就像一个HashTable，给一个KeyName，就可以知道目前的KeyValue是什么，然后手工实现键值数据递增。在SQL Server中可以编写这样一个存储过程，让取键值的过程自动进行。代码如下：
CREATE
PROCEDURE
[
GetKey
]
@KeyName char(
10),
@KeyValue int OUTPUT
AS
UPDATE IntKey
SET @KeyValue
= KeyValue
= KeyValue
+
1
WHERE KeyName
= @KeyName
GO
这样，通过调用存储过程，我们可以获得最新键值，确保不会出现重复。若将OrderID字段设置为手动增长型字段，我们的程序可以由以下几步来实现：首先调用存储过程，获得一个OrderID，然后使用这个OrderID填充Order表与OrderDetail表，最后在事务保护下对两表进行更新。
使用手动增长型字段作为主键在进行数据库间数据复制时，可以确保数据合并过程中不会出现键值冲突，只要我们为不同的数据库分配不同的主键取值段就行了。但是，使用手动增长型字段会增加网络的RoundTrip，我们必须通过增加一次数据库访问来获取当前主键键值，这会增加网络和数据库的负载，当处于一个低速或断开的网络环境中时，这种做法会有很大的弊端。同时，手工维护主键还要考虑并发冲突等种种因素，这更会增加系统的复杂程度。
3使用UniqueIdentifier
SQL Server为我们提供了UniqueIdentifier数据类型，并提供了一个生成函数NEWID( )，使用NEWID( )可以生成一个唯一的UniqueIdentifier。UniqueIdentifier在数据库中占用16个字节，出现重复的概率非常小，以至于可以认为是0。我们经常从注册表中看到类似
{45F0EB02-0727-4F2E-AAB5-E8AEDEE0CEC5}
的东西实际上就是一个UniqueIdentifier，Windows用它来做COM组件以及接口的标识，防止出现重复。在.NET里管UniqueIdentifier称之为GUID（Global Unique Identifier）。在C#中可以使用如下命令生成一个GUID：
Guid u = System.Guid.NewGuid();
对于上面提到的Order与OrderDetail的程序，如果选用UniqueIdentifier作为主键的话，我们完全可以避免上面提到的增加网络RoundTrip的问题。通过程序直接生成GUID填充主键，不用考虑是否会出现重复。
UniqueIdentifier字段也存在严重的缺陷：首先，它的长度是16字节，是整数的4倍长，会占用大量存储空间。更为严重的是，UniqueIdentifier的生成毫无规律可言，要想在上面建立索引（绝大多数数据库在主键上都有索引）是一个非常耗时的操作。有人做过实验，插入同样的数据量，使用UniqueIdentifier型数据做主键要比使用Integer型数据慢，所以，出于效率考虑，尽可能避免使用UniqueIdentifier型数据库作为主键键值。
4使用“COMB（Combine）”类型
既然上面三种主键类型选取策略都存在各自的缺点，那么到底有没有好的办法加以解决呢？答案是肯定的。通过使用COMB类型（数据库中没有COMB类型，它是Jimmy Nilsson在他的“The Cost of GUIDs as Primary Keys”一文中设计出来的），可以在三者之间找到一个很好的平衡点。
COMB数据类型的基本设计思路是这样的：既然UniqueIdentifier数据因毫无规律可言造成索引效率低下，影响了系统的性能，那么我们能不能通过组合的方式，保留UniqueIdentifier的前10个字节，用后6个字节表示GUID生成的时间（DateTime），这样我们将时间信息与UniqueIdentifier组合起来，在保留UniqueIdentifier的唯一性的同时增加了有序性，以此来提高索引效率。也许有人会担心UniqueIdentifier减少到10字节会造成数据出现重复，其实不用担心，后6字节的时间精度可以达到1/300秒，两个COMB类型数据完全相同的可能性是在这1/300秒内生成的两个GUID前10个字节完全相同，这几乎是不可能的！在SQL Server中用SQL命令将这一思路实现出来便是：
DECLARE @aGuid UNIQUEIDENTIFIER
SET @aGuid
=
CAST(
CAST(
NEWID()
AS BINARY(
10))
+
CAST(
GETDATE()
AS BINARY(
6))
AS UNIQUEIDENTIFIER)
经过测试，使用COMB做主键比使用INT做主键，在检索、插入、更新、删除等操作上仍然显慢，但比Unidentifier类型要快上一些。关于测试数据可以参考我2004年7月21日的随笔。
除了使用存储过程实现COMB数据外，我们也可以使用C#生成COMB数据，这样所有主键生成工作可以在客户端完成。C#代码如下：
//
================================================================
///<summary>
/// 返回 GUID 用于数据库操作，特定的时间代码可以提高检索效率/// </summary>
/// <returns>COMB (GUID 与时间混合型) 类型 GUID 数据</returns>
public
static Guid NewComb()
{
byte[] guidArray = System.Guid.NewGuid().ToByteArray();
DateTime baseDate =
new DateTime(1900,1,1);
DateTime now = DateTime.Now;
//
Get the days and milliseconds which will be used to build the byte string
TimeSpan days =
new TimeSpan(now.Ticks - baseDate.Ticks);
TimeSpan msecs =
new TimeSpan(now.Ticks - (
new DateTime(now.Year, now.Month, now.Day).Ticks));
//
Convert to a byte array
//
Note that SQL Server is accurate to 1/300th of a millisecond so we divide by 3.333333
byte[] daysArray = BitConverter.GetBytes(days.Days);
byte[] msecsArray = BitConverter.GetBytes((
long)(msecs.TotalMilliseconds/3.333333));
//
Reverse the bytes to match SQL Servers ordering
Array.Reverse(daysArray);
Array.Reverse(msecsArray);
//
Copy the bytes into the guid
Array.Copy(daysArray, daysArray.Length - 2, guidArray, guidArray.Length - 6, 2);
Array.Copy(msecsArray, msecsArray.Length - 4, guidArray, guidArray.Length - 4, 4);
return
new System.Guid(guidArray);
}
//
================================================================
/// <summary>/// 从 SQL SERVER 返回的 GUID 中生成时间信息/// </summary>/// <param name="guid">包含时间信息的 COMB </param>/// <returns>时间</returns>
public
static DateTime GetDateFromComb(System.Guid guid)
{ DateTime baseDate =
new DateTime(1900,1,1);
byte[] daysArray =
new
byte[4];
byte[] msecsArray =
new
byte[4];
byte[] guidArray = guid.ToByteArray();
//
Copy the date parts of the guid to the respective byte arrays.
Array.Copy(guidArray, guidArray.Length - 6, daysArray, 2, 2);
Array.Copy(guidArray, guidArray.Length - 4, msecsArray, 0, 4);
//
Reverse the arrays to put them into the appropriate order
Array.Reverse(daysArray);
Array.Reverse(msecsArray);
//
Convert the bytes to ints
int days = BitConverter.ToInt32(daysArray, 0);
int msecs = BitConverter.ToInt32(msecsArray, 0);
DateTime date = baseDate.AddDays(days);
date = date.AddMilliseconds(msecs * 3.333333);
return date;
}
1347
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
