sqlserver主键设计的注意点

在设计主键的时候往往需要考虑以下几点:

1.无意义性:此处无意义是从用户的角度来定义的。这种无意义在一定程度上也会减少数据库的信息冗余。常常有人称呼主键为内部标识,为什么会这样称呼,原因之一在于“内部”,所谓内部从某种程度上来说就是指表记录,从大的范围来说就是数据库,如果你在设计的时候选择了对用户来说有意义的信息来作为主键,那么迟早会面对用户提出对这块信息进行更新的需求,那么你就违背了它应有的静态。

2.静态性:主键除了唯一地标识一条记录及外键的关联外,应不再考虑其他的意义,最理想的状态就是在产生后不再变动,所以在主键值产生后应考虑不对他进行更新等操作。如果进行了更新操作那么至少说明这块信息对于用户来说是有一定的意义,那么你就违背了应有的无意义性。(对数据进行整合等操作时可能需要对主键进行处理,这样做是为了保证数据库的完整性——记录的唯一,不在此考虑范围之内。)

无意义性往往可以决定其静态性。

3.简短性:既包含主键组成字段数量要少,还包含主键中单个字段存储类型简短,一般采用整形;对于前者主要考虑的是外键关联的因素;对于后者主要考虑的是性能。主键的简短对表的关联便捷性及检索的性能有极大的帮助。

看看下面具有缺陷的“主生产计划表”主键设计方案(MsSQL):

复制代码 代码如下:

--主表

CREATE TABLE PP_MPSHeader(

  BillNo VARCHAR(20) NOT NULL PRIMARY KEY,

  PlanDate DATETIME NOT NULL

)

--从表

CREATE TABLE PP_MPSBody(

  BillNo VARCHAR(20) NOT NULL,

  LineNumber SMALLINT NOT NULL,

  ProductID INT NOT NULL,

  ProductQty DECIMAL(18,2) NOT NULL,

PRIMARY KEY(BillNo,LineNumber)

)

--设置外键

ALTER TABLE PP_MPSBody

ADD CONSTRAINT FK_PP_MPSHeader_MPSBody FOREIGN KEY(BillNo) REFERENCES PP_MPSHeader(BillNo)

这是典型的主从表结构。主表记录什么时候下达哪个单号的主计划,从表记录的是此计划生产哪些产品各多少数量,通过BillNo进行关联。当用户在下达一份主生产计划后,很可能会发现由于粗心大意输错了BillNo中计划单号信息,那么在他修改单号时,代码编写者需要在代码中控制从表的单号跟随主表的单号进行变动,否则单据将在外键的约束下无法保存,如果没有外键的约束,那么数据将失去其完整性。

如果按照上面的3个注意点,解决方案如下(MsSQL):

复制代码 代码如下:

--主表

CREATE TABLE PP_MPSHeader(

  BillId INT PRIMARY KEY,

  BillNo VARCHAR(20) NOT NULL,

  PlanDate DATETIME NOT NULL

)

--从表

CREATE TABLE PP_MPSBody(

  BillId INT PRIMARY KEY,

  LineNumber SMALLINT NOT NULL,

  ProductID INT NOT NULL,

  ProductQty DECIMAL(18,2) NOT NULL,

PRIMARY KEY(BillId,LineNumber)

)

--设置外键

ALTER TABLE PP_MPSBody

ADD CONSTRAINT FK_PP_MPSHeader_MPSBody FOREIGN KEY(BillId) REFERENCES PP_MPSHeader(BillId)

现在,主从表通过BillId进行关联,当产生一份生产计划时,生成一个BillId,对于用户来说根本没有意义,在随后单据信息的改动中也不会出现上面的主从信息协调问题。同时从表的信息量小于上面的缺陷设计。因为原外键BillNo的长度从20个字节变成了现在的BillId4个字节,减少了信息的冗余。

这样的例子其实很多,比如:

有的设计原材料表时,使用零部件图号作为主键,那就意味着采购、生产、销售等等相关表中都会出现零部件图号的外键信息,当零部件图号信息发生变动时,这些所有先关的信息都需要跟着变动,这种缺陷如果不从根本上解决,那么你可能需要写个零部件图号变动处理过程,来批量处理这些问题,在处理的过程中可能你还得考虑处理的顺序问题……;

有的设计,使用身份证件号作为人员表的主键,但是身份证后来从15位变成了18位,这就意味着人员表中每个人的人员身份证信息都需要变动,如果你是某个社保机构此应用程序的设计人员,那么你就需要更新上百万条记录;那些所有由人员表通过身份证件号外联出去的信息记录将会以亿计数,那么也许余生你就不需要做其他工作了。

所以选择无意义的键值来作为主键的一部分,也是从长远意义上来避免类似这种改动的发生。

时间: 2024-09-30 12:37:51

sqlserver主键设计的注意点的相关文章

SQL Server表的主键设计应注意的问题

关于数据库的逻辑设计,是一个很广泛的问题.本文主要针对开发应用中遇到在MS SQL Server上进行表设计时,对表的主键设计应注意的问题以及相应的解决办法. 主键设计现状和问题 关于数据库表的主键设计,一般而言,是根据业务需求情况,以业务逻辑为基础,形成主键. 比如,销售时要记录销售情况,一般需要两个表,一个是销售单的概要描述,记录诸如销售单号.总金额一类的情况,另外一个表记录每种商品的数量和金额.对于第一个表(主表),通常我们以单据号为主键;对于商品销售的明细表(从表),我们就需要将主表的单

SQL SERVER数据库表主键设计

1. 序言 当前,随着信息量的急剧增加,对于数据的存储和管理方式,各企业都逐渐摆脱了之前的依靠文件系统(文本文件或者Excel)或者一些桌面型的小型数据库系统(如Access.FoxBASE或者DBase)的状态,转而通过一些大型数据库来管理企业的信息.这些大型数据库系统包括Oracle.MS SQL Server或者IBM DB2.尽管目前数据库系统也在向面向对象的数据库系统方向发展,但是上述的传统的关系型数据库系统依然占据着主要位置. 笔者从九十年代末开始以关系型数据库系统为基础为客户进行管

SQL Server上进行表设计时表的主键设计问题

关于数据库的逻辑设计,是一个很广泛的问题.本文主要针对开发应用中遇到在MS SQL Server上进行表设计时,对表的主键设计应注意的问题以及相应的解决办法. 主键设计现状和问题 关于数据库表的主键设计,一般而言,是根据业务需求情况,以业务逻辑为基础,形成主键. 比如,销售时要记录销售情况,一般需要两个表,一个是销售单的概要描述,记录诸如销售单号.总金额一类的情况,另外一个表记录每种商品的数量和金额.对于第一个表(主表),通常我们以单据号为主键;对于商品销售的明细表(从表),我们就需要将主表的单

MySQL主键设计

原文:MySQL主键设计 [TOC] 在项目过程中遇到一个看似极为基础的问题,但是在深入思考后还是引出了不少问题,觉得有必要把这一学习过程进行记录. MySQL主键设计原则 MySQL主键应当是对用户没有意义的. MySQL主键应该是单列的,以便提高连接和筛选操作的效率 永远也不要更新MySQL主键 MySQL主键不应包含动态变化的数据,如时间戳.创建时间列.修改时间列等 MySQL主键应当有计算机自动生成. 主键设计的常用方案 自增ID 优点: 1.数据库自动编号,速度快,而且是增量增长,聚集

SQLServer主键和唯一约束的区别_MsSql

首先说明一点,主键又称主键约束,它也是一种约束,看下它和唯一约束的创建语法: alter table Person add constraint PK_Id primary key (Id) alter table Person add constraint UQ_Name unique (Name) 主键和唯一约束都要求字段值唯一,除此外,它们还有如下区别: ·同一张表只能有一个主键,但能有多个唯一约束: ·主键字段值不能为NULL,唯一约束字段值可以为NULL: ·主键字段可以做为其他表的外

SQLServer主键和唯一约束的区别

首先说明一点,主键又称主键约束,它也是一种约束,看下它和唯一约束的创建语法: alter table Person add constraint PK_Id primary key (Id) alter table Person add constraint UQ_Name unique (Name) 主键和唯一约束都要求字段值唯一,除此外,它们还有如下区别: ·同一张表只能有一个主键,但能有多个唯一约束: ·主键字段值不能为NULL,唯一约束字段值可以为NULL: ·主键字段可以做为其他表的外

数据库模型设计——主键的设计

在数据库设计时,主要就是对实体和关系的设计,实体表现出来就是表,关系表现出来就是外键.而对于一个表,由两部分组成:主键和属性.主键的简单定义就是表中为每一行数据的唯一标识.其实更准确的说法,每一行数据的唯一标识是候选键(Candidate Key),一个表中可以有很多个候选键,主键是候选键中的一个,主要用于更方便的检索和管理数据.一个表中可以有多个候选键,但是只有一个主键.由于主键常常用于检索数据,也用于表之间的关联,所以主键的设计的好坏将会严重影响数据操作的性能.下面来介绍下主键设计的几个考虑

数据库中主键和外键的设计原则

主键和外键是把多个表组织为一个有效的关系数据库的粘合剂.主键和外键的设计对物理数据库的性能和可用性都有着决定性的影响.      必须将数据库模式从理论上的逻辑设计转换为实际的物理设计.而主键和外键的结构是这个设计过程的症结所在.一旦将所设计的数据库用于了生产环境,就很难对这些键进行修改,所以在开发阶段就设计好主键和外键就是非常必要和值得的.  首先来谈:主键.  关系数据库依赖于主键 --- 它是数据库物理模式的基石.主键在物理层面上只有两个用途: 1. 惟一地标识一行. 2. 作为一个可以被

数据库主键设计之思考

主键的必要性: 有些朋友可能不提倡数据库表必须要主键,但在我的思考中,觉得每个表都应该具有主键,不管是单主键还是双主键,主键的存在就代表着表结构的完整性,表的记录必须得有唯一区分的字段,主键主要是用于其他表的外键关联,本记录的修改与删除,当我们没有主键时,这些操作会变的非常麻烦. 主键的无意义性: 我强调主键不应该具有实际的意义,这可能对于一些朋友来说不太认同,比如订单表吧,会有"订单编号"字段,而这个字段呢在业务实际中本身就是应该具有唯一性,具有唯一标识记录的功能,但我是不推荐采用订