数据库主键与外键

合集下载

数据库中主键与外键的约束与维护策略

数据库中主键与外键的约束与维护策略

数据库中主键与外键的约束与维护策略在数据库设计和实现过程中,主键与外键是两个重要的概念。

主键是用来唯一标识数据库表中每一条记录的字段或字段组合,而外键是用来建立表与表之间关联关系的字段。

主键和外键的约束与维护策略在数据库中非常重要,它们能够保证数据的完整性和一致性。

本文将重点讨论数据库中主键和外键的约束与维护策略。

1. 主键的约束与维护策略主键的作用是唯一标识每一条记录,保证数据的唯一性和完整性。

在数据库中,主键可以是一个字段,也可以是多个字段的组合。

主键的约束与维护策略主要有以下几种:1.1 唯一性约束:主键字段的值在整个表中是唯一的,不能重复。

数据库会自动检查主键的唯一性,并在插入或更新数据时进行验证。

如果违反唯一性约束,数据库会拒绝相应的操作。

1.2 非空约束:主键字段不能为NULL值,必须有值。

数据库会在插入数据时验证主键字段是否为空,如果为空则拒绝插入操作。

1.3 持久性约束:主键字段的值是持久的,即不会随着时间的推移而变化。

在实际应用中,主键通常使用自增长的整数类型,以保证持久性约束。

1.4 索引约束:主键字段通常会创建唯一索引,以提高查询性能。

索引可以加快主键字段的查找速度,使查询更加高效。

2. 外键的约束与维护策略外键用于建立表与表之间的关联关系,以维护数据之间的引用完整性。

外键字段通常用来和其他表的主键建立关系,确保关联数据的一致性。

外键的约束与维护策略主要有以下几种:2.1 引用完整性约束:外键字段的值必须引用目标表中存在的主键值,确保关联数据的完整性。

在插入或更新数据时,数据库会验证外键字段的引用完整性,如果违反约束则拒绝相应的操作。

2.2 级联操作:在关联表的数据发生变化时,可以通过级联操作来维护数据的关联关系。

常见的级联操作有级联删除和级联更新。

- 级联删除:当主表中的记录被删除时,相关联的外键表中的记录也会被自动删除。

这样可以保证数据的完整性,避免出现孤立的数据。

- 级联更新:当主表中的主键值被更新时,相关联的外键表中的外键值也会被自动更新。

数据库主键与外键约束

数据库主键与外键约束

数据库主键与外键约束数据库是一个存储和管理结构化数据的庞大系统。

在数据库中,主键与外键约束是两个重要的概念,它们在确保数据完整性和关联性方面起着关键作用。

本文将详细介绍数据库主键与外键约束的定义、作用以及使用方法。

1. 主键约束主键是指一个表中唯一标识每一条记录的字段或字段组合。

主键在数据库中具有以下特性:1.1 唯一性:主键的值在表中必须唯一,不能重复。

1.2 非空:主键的值不能为空,不能为NULL。

1.3 不可变性:主键的值一旦确定,就不能修改或者被删除。

主键约束的作用:1. 提供唯一标识:主键通过唯一标识每一条记录,便于数据的定位和管理。

2. 防止重复数据:主键约束能够防止用户插入重复的数据,确保数据的一致性。

3. 提高查询效率:数据库引擎会自动为主键创建索引,加快查询速度。

主键约束的使用方法:1. 定义主键字段:可以在表的创建语句中使用PRIMARY KEY关键字定义主键字段,也可以通过修改表结构的方式添加主键约束。

2. 主键字段的约束类型:主键字段可以是整型、字符型或者复合字段。

3. 主键的选择:选择具有唯一性、简洁性和稳定性的字段作为主键。

2. 外键约束外键是指一个表中的字段,它用来建立与另一个表的关联关系。

外键约束用于保持数据之间的引用完整性,确保数据的一致性。

外键约束具有以下特性:2.1 引用完整性:外键约束保证关联表中的外键值必须存在于被引用表中的主键中。

2.2 删除和更新操作:外键约束可以定义级联更新或级联删除等操作,以保持关联数据的一致性。

2.3 多对一关系:一个表可以有多个外键约束,用于建立与其他表的多对一关系。

外键约束的作用:1. 维护数据关联:外键约束保证了表与表之间的关联关系,确保数据在相关表之间的正确性和一致性。

2. 防止脏数据:外键约束可以阻止用户插入无效的外键值,从而避免脏数据的产生。

3. 级联操作:外键约束可以自动进行级联更新和级联删除操作,提高数据操作的效率和一致性。

数据库设计中的主键和外键使用准则(三)

数据库设计中的主键和外键使用准则(三)

数据库设计中的主键和外键使用准则引言在数据库设计中,主键和外键是关键概念,它们在保证数据完整性和数据关联性方面起着至关重要的作用。

本文将介绍数据库设计中主键和外键的使用准则。

一、主键的选择与设计主键是用于唯一标识数据库表中的每一条记录的字段或字段组合。

正确选择和设计主键对于数据库的性能和数据一致性具有重要影响。

1. 选择单一字段作为主键:单一字段作为主键的优点是简单明确,容易理解和实现。

一般情况下,应选择一个不可变且唯一的字段作为主键,例如自增字段、身份证号等。

2. 复合主键的使用:某些情况下,单一字段无法唯一标识一条记录,这时需要使用复合主键。

复合主键是由多个字段组成的,共同保证记录的唯一性。

在选择复合主键时,应注意不要选择过多的字段,以避免影响性能。

3. 避免使用敏感信息作为主键:主键在外键关联等场景中会被暴露出来,因此应避免使用敏感信息作为主键,如手机号、邮箱等。

二、外键的使用准则外键是用于建立数据库表之间关系的字段,它能够保证表与表之间的数据一致性。

以下是关于外键使用准则的探讨。

1. 选择正确的外键关联关系:外键关联关系分为一对一、一对多和多对多三种类型。

在建立关联关系时,应根据实际需求选择合适的关系类型。

2. 引入外键约束:引入外键约束可以保证数据的一致性,避免出现脏数据。

外键约束可以限制外键字段的取值范围,只允许参照被关联表的合法主键值。

3. 级联操作的谨慎使用:级联操作是外键的一个重要属性,可以在主表进行更新或删除操作时,自动更新或删除相关联的记录。

然而,滥用级联操作可能导致数据的异常修改或误删除。

因此,在使用级联操作时,应慎重考虑,并进行充分测试。

4. 外键的性能影响:外键的存在可能会降低数据库的性能,因为在查找和插入数据时需要额外的查询操作。

为了提高性能,可以考虑使用索引来优化外键的检索效率。

三、其他注意事项除了上述两个准则之外,还有一些其他需要注意的事项,如下:1. 主键和外键的命名:命名主键和外键时,应使用有意义的字段名,并且命名要规范统一,便于清晰理解和维护。

数据库的几个概念:主键,外键,索引,唯一索引

数据库的几个概念:主键,外键,索引,唯一索引

数据库的几个概念:主键,外键,索引,唯一索引主键:主键是数据表的唯一索引,比如学生表里有学号和姓名,姓名可能有重名的,但学号确是唯一的,你要从学生表中搜索一条纪录如查找一个人,就只能根据学号去查找,这才能找出唯一的一个,这就是主键;如:id int(10) not null primary key auto_increment ;自增长的类型;外键:定义数据表假如某个电脑生产商,它的数据库中保存着整机和配件的产品信息。

用来保存整机产品信息的表叫做 Pc;用来保存配件供货信息的表叫做Parts。

在Pc表中有一个字段,用来描述这款电脑所使用的CPU型号;在Parts 表中相应有一个字段,描述的正是CPU的型号,我们可以把它想成是全部CPU的型号列表。

很显然,这个厂家生产的电脑,其使用的CPU一定是供货信息表(parts)中存在的型号。

这时,两个表中就存在一种约束关系(constraint)——Pc表中的CPU型号受到Parts 表中型号的约束。

首先我们来创建 parts 表:CREATE TABLE parts (... 字段定义 ...,model VARCHAR(20) NOT NULL,... 字段定义 ...);接下来是Pc表:CREATE TABLE pc (... 字段定义 ...,cpumodel VARCHAR(20) NOT NULL,... 字段定义 ...};设置索引若要设置外键,在参照表(referencing table,即Pc表) 和被参照表(referenced table,即parts表) 中,相对应的两个字段必须都设置索引(index)。

对Parts表:ALTER TABLE parts ADD INDEX idx_model (model);这句话的意思是,为 parts 表增加一个索引,索引建立在 model 字段上,给这个索引起个名字叫idx_model。

对Pc表也类似:ALTER TABLE pc ADD INDEX idx_cpumodel (cpumodel);事实上这两个索引可以在创建表的时候就设置。

数据库中的主键与外键介绍

数据库中的主键与外键介绍

2手动增长型字段既然自动增长型字段会带来如此的麻烦,我们不妨考虑使用手动增长型的字段,也就是说主键的值需要自己维护,通常情况下需要建立一张单独的表存储当前主键键值。还用上面的例子来说,这次我们新建一张表叫IntKey,包含两个字段,KeyName以及KeyValue。就像一个HashTable,给一个KeyName,就可以知道目前的KeyValue是什么,然后手工实现键值数据递增。在SQL
Server中可以编写这样一个存储过程,让取键值的过程自动进行。代码如下:
CREATE PROCEDURE[GetKey]
@KeyNamechar(10),
@KeyValue intOUTPUT AS UPDATE IntKey SET @KeyValue =KeyValue = KeyValue + 1
定义主键和外键主要是为了维护关系数据库的完整性,总结一下:
主键是能确定一条记录的唯一标识,比如,一条记录包括身份证号,姓名,年龄。身份证号是唯一能确定你这个人的,其他都可能有重复,所以,身份证号是主键。
外键用于与另一张表的关联。是能确定另一张表记录的字段,用于保持数据的一致性。比如,A表中的一个字段,是B表的主键,那他就可以是A表的外键。
COMB数据类型的基本设计思路是这样的:既然UniqueIdentifier数据因毫无规律可言造成索引效率低下,影响了系统的性能,那么我们能不能通过组合的方式,保留UniqueIdentifier的前10个字节,用后6个字节表示GUID生成的时间(DateTime),这样我们将时间信息与UniqueIdentifier组合起来,在保留UniqueIdentifier的唯一性的同时增加了有序性,以此来提高索引效率。也许有人会担心UniqueIdentifier减少到10字节会造成数据出现重复,其实不用担心,后6字节的时间精度可以达到1/300秒,两个COMB类型数据完全相同的可能性是在这1/300秒内生成的两个GUID前10个字节完全相同,这几乎是不可能的!在SQL

MySQL主键和外键设计原则和实践

MySQL主键和外键设计原则和实践

MySQL主键和外键设计原则和实践在数据库设计中,主键和外键是两个非常重要的概念。

它们不仅可以用来保证数据的完整性,还可以提高数据库的性能和查询效率。

本文将介绍MySQL主键和外键的设计原则和实践,帮助读者更好地理解和应用这两个概念。

1. 主键的定义和作用主键是一列或一组列,其值用于唯一标识数据库表中的每一行数据。

主键具有以下作用:1.1 唯一性约束:主键的值在整个表中必须是唯一的,用于区分不同的数据行。

1.2 非空约束:主键的值不能为NULL,确保每一行都有一个有效的标识。

1.3 快速查询:主键通常会被用作索引,可以提高查询的效率。

2. 主键的选择选择适合的主键是一个关键的设计决策。

以下是几个常见的主键选择:2.1 单列主键:在表中选择一个唯一的列作为主键,通常是自增长的整数列。

这种选择简单和高效,但在分布式环境中可能存在性能问题。

2.2 复合主键:在表中选择多个列作为主键,结合这些列的值可以唯一标识数据行。

这种选择适用于需要联合索引的情况,但也增加了数据库的复杂性。

2.3 外部主键:引用其他表中的列作为主键。

这种选择可以建立表与表之间的关联,但也需要额外的管理和维护工作。

3. 外键的定义和作用外键是一列或一组列,其值用于建立表与表之间的关联。

外键具有以下作用:3.1 关联表之间的数据:通过外键可以建立表与表之间的联系,实现数据的引用和关联。

3.2 维护数据的完整性:外键可以强制保证关联表中的数据的完整性,确保数据的一致性和准确性。

3.3 改善查询性能:外键可以作为索引,提高查询的效率。

4. 外键的设计原则在设计外键时,应遵循以下原则来确保数据库表的结构合理和高效:4.1 唯一性约束:外键的值在引用表中必须是唯一的,有助于避免数据的冗余和不一致。

4.2 对应关系:外键的值必须与被引用表的主键值相对应,确保数据的一致性。

4.3 级联操作:对于涉及到关联表的插入、更新和删除操作,可以设置级联操作规则来保持数据的一致性和完整性。

数据库主键和外键

数据库主键和外键

数据库主键和外键一、什么是主键、外键:关系型数据库中的一条记录中有若干个属性,若其中某一个属性组(注意是组)能唯一标识一条记录,该属性组就可以成为一个主键比如学生表(学号,姓名,性别,班级)其中每个学生的学号是唯一的,学号就是一个主键课程表(课程编号,课程名,学分)其中课程编号是唯一的,课程编号就是一个主键成绩表(学号,课程号,成绩)成绩表中单一一个属性无法唯一标识一条记录,学号和课程号的组合才可以唯一标识一条记录,所以学号和课程号的属性组是一个主键成绩表中的学号不是成绩表的主键,但它和学生表中的学号相对应,并且学生表中的学号是学生表的主键,则称成绩表中的学号是学生表的外键同理成绩表中的课程号是课程表的外键定义主键和外键主要是为了维护关系数据库的完整性,总结一下:主键是能确定一条记录的唯一标识,比如,一条记录包括身份正号,姓名,年龄。

身份证号是唯一能确定你这个人的,其他都可能有重复,所以,身份证号是主键。

外键用于与另一张表的关联。

是能确定另一张表记录的字段,用于保持数据的一致性。

比如,A表中的一个字段,是B表的主键,那他就可以是A表的外键。

二、主键、外键和索引的区别收藏主键、外键和索引的区别?聚集索引和非聚集索引的区别?聚集索引一定是唯一索引。

但唯一索引不一定是聚集索引。

聚集索引,在索引页里直接存放数据,而非聚集索引在索引页里存放的是索引,这些索引指向专门的数据页的数据。

三、数据库中主键和外键的设计原则主键和外键是把多个表组织为一个有效的关系数据库的粘合剂。

主键和外键的设计对物理数据库的性能和可用性都有着决定性的影响。

必须将数据库模式从理论上的逻辑设计转换为实际的物理设计。

而主键和外键的结构是这个设计过程的症结所在。

一旦将所设计的数据库用于了生产环境,就很难对这些键进行修改,所以在开发阶段就设计好主键和外键就是非常必要和值得的。

主键:关系数据库依赖于主键---它是数据库物理模式的基石。

主键在物理层面上只有两个用途:1. 惟一地标识一行。

了解MySQL的主键和外键的作用与设计原则

了解MySQL的主键和外键的作用与设计原则

了解MySQL的主键和外键的作用与设计原则引言:数据库是计算机科学中非常重要的概念,它用于存储和管理结构化数据。

MySQL是最常用的关系型数据库管理系统之一,被广泛应用于各个领域。

本文将深入探讨MySQL中主键和外键的作用与设计原则。

主键和外键是数据库中关系模型中的重要概念,它们用于建立表与表之间的关系。

一、主键的作用与设计原则主键是表中的唯一标识符。

它的作用是用于确保数据的唯一性和快速检索。

主键的设计原则如下:1. 唯一性:主键的值必须在整个表中是唯一的,用来标识表中的每一行数据。

可以选择一个或多个列作为主键,如果选择多个列,则这些列的组合必须唯一。

2. 不可为空:主键的值不能为空。

这样可以避免出现无效数据。

3. 稳定性:主键的值应尽量稳定,不应该经常变动。

因为主键被用作索引,如果频繁修改主键值,会导致索引频繁更新,影响数据库性能。

4. 简洁性:主键的值应该尽量简洁,以确保执行效率和空间利用率。

5. 具有实际意义:主键的值最好具有实际意义,便于开发人员和用户理解和维护。

二、外键的作用与设计原则外键用于建立表与表之间的关联关系。

它的作用是用于维护表之间的一致性和完整性。

外键的设计原则如下:1. 关联性:外键用于表与表之间的关联,必须指向其他表的主键。

2. 级联操作:外键可以设置级联操作,当关联的主键值发生变化或被删除时,外键也会相应地变化或被删除,确保数据的一致性。

3. 存在性:外键的值必须在关联表中存在,这样可以保证数据的完整性。

4. 空值允许:外键的值可以为空,表示该关联可以为空。

5. 数据类型要一致:外键和关联的主键数据类型必须一致,方便建立有效的关联关系。

6. 性能与索引:外键的使用应考虑性能和索引的影响。

如果外键的查询频繁,可以对外键列建立索引,以提高查询效率。

三、主键和外键的使用场景主键和外键在数据库设计中有许多使用场景,下面介绍几个常见的场景:1. 基本表关系:有些表之间的关系是一对一或一对多的关系,使用外键可以帮助维护表之间的关联性。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

聚集索引一定是唯一索引。

但唯一索引不一定是聚集索引。

聚集索引,在索引页里直接存放数据,而非聚集索引在索引页里存放的是索引,这些索引指向专门的数据页的数据。

三、数据库中主键和外键的设计原则主键和外键是把多个表组织为一个有效的关系数据库的粘合剂。

主键和外键的设计对物理数据库的性能和可用性都有着决定性的影响。

必须将数据库模式从理论上的逻辑设计转换为实际的物理设计。

而主键和外键的结构是这个设计过程的症结所在。

一旦将所设计的数据库用于了生产环境,就很难对这些键进行修改,所以在开发阶段就设计好主键和外键就是非常必要和值得的。

主键:关系数据库依赖于主键---它是数据库物理模式的基石。

主键在物理层面上只有两个用途: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到底该不该自动增长呢?允许我们在DataSet中将某一个字段设置为自动增长型字段,但千万记住,这个自动增长字段仅仅是个占位符而已,当数据库进行更新时,数据库生成的值会自动取代分配的值。

所以为了防止用户产生误解,建议大家将中的自动增长初始值以及增量都设置成-1。

此外,在中,我们可以为两张表建立DataRelation,这样存在级联关系的两张表更新时,一张表更新后另外一张表对应键的值也会自动发生变化,这会大大减少了我们对存在级联关系的两表间更新时自动增长型字段带来的麻烦。

2手动增长型字段既然自动增长型字段会带来如此的麻烦,我们不妨考虑使用手动增长型的字段,也就是说主键的值需要自己维护,通常情况下需要建立一张单独的表存储当前主键键值。

还用上面的例子来说,这次我们新建一张表叫IntKey,包含两个字段,KeyName以及KeyValue。

就像一个HashTable,给一个KeyName,就可以知道目前的KeyValue是什么,然后手工实现键值数据递增。

在SQL Server中可以编写这样一个存储过程,让取键值的过程自动进行。

代码如下:CREATE PROCEDURE[GetKey]@KeyName char(10),@KeyValue int OUTPUTASUPDATE IntKey SET @KeyValue = KeyValue = KeyValue +1WHERE KeyName = @KeyNameGO这样,通过调用存储过程,我们可以获得最新键值,确保不会出现重复。

若将OrderID字段设置为手动增长型字段,我们的程序可以由以下几步来实现:首先调用存储过程,获得一个OrderID,然后使用这个OrderID填充Order表与OrderDetail表,最后在事务保护下对两表进行更新。

使用手动增长型字段作为主键在进行数据库间数据复制时,可以确保数据合并过程中不会出现键值冲突,只要我们为不同的数据库分配不同的主键取值段就行了。

但是,使用手动增长型字段会增加网络的RoundTrip,我们必须通过增加一次数据库访问来获取当前主键键值,这会增加网络和数据库的负载,当处于一个低速或断开的网络环境中时,这种做法会有很大的弊端。

同时,手工维护主键还要考虑并发冲突等种种因素,这更会增加系统的复杂程度。

3使用UniqueIdentifierSQL 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 UNIQUEIDENTIFIERSET @aGuid =CAST(CAST(NEWID() AS BINARY(10))+CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER)经过测试,使用COMB做主键比使用INT做主键,在检索、插入、更新、删除等操作上仍然显慢,但比Unidentifier类型要快上一些。

相关文档
最新文档