MSSQL - 逻辑主键、业务主键和复合主键

转载自:http://blog.csdn.net/sunrise918/article/details/5575054

这几天对逻辑主键、业务主键和复合主键进行了一些思考,也在网上搜索了一下相关的讨论,相关讨论可以看最下面的参考链接。下面是自己基于 SQL Server 做的一些总结,其他数据库(Oracle、MySQL、DB2、......)应该也类似吧。这个只是自己一时的思考,如有不当请告知,重新思考后再修 正。

定义(部分定义来源于 SQL Server 联机丛书):

主键(PRIMARY KEY):表通常具有包含唯一标识表中每一行的值的一列或一组列。这样的一列或多列称为表的主键 (PK),用于强制表的实体完整性。

外键(FOREIGN KEY):外键 (FK) 是用于建立和加强两个表数据之间的链接的一列或多列。在外键引用中,当一个表的列被引用作为另一个表的主键值的列时,就在两表之间创建了链接。这个列就成为第二个表的外键。

聚集索引:聚集索引基于数据行的键值在表内排序和存储这些数据行。每个表只能有一个聚集索引,因为数据行本身只能按一个顺序存储。

非聚集索引:非聚集索引包含索引键值和指向表数据存储位置的行定位器。可以对表或索引视图创建多个非聚集索引。通常,设计非聚集索引是为改善经常使用的、没有建立聚集索引的查询的性能。

自动编号列和标识符列:对于每个表,均可创建一个包含系统生成的序号值的标识符列,该序号值以唯一方式标识表中的每一行。

业务主键(自然主键):在数据库表中把具有业务逻辑含义的字段作为主键,称为“自然主键(Natural Key)”。

逻辑主键(代理主键):在数据库表中采用一个与当前表中逻辑信息无关的字段作为其主键,称为“代理主键”。

复合主键(联合主键):通过两个或者多个字段的组合作为主键。

原理分析:

使用逻辑主键的主要原因是,业务主键一旦改变则系统中关联该主键的部分的修改将会是不可避免的,并且引用越多改动越大。而使用逻辑主键则只需要修改 相应的业务主键相关的业务逻辑即可,减少了因为业务主键相关改变对系统的影响范围。业务逻辑的改变是不可避免的,因为“永远不变的是变化”,没有任何一个 公司是一成不变的,没有任何一个业务是永远不变的。最典型的例子就是身份证升位和驾驶执照号换用身份证号的业务变更。而且现实中也确实出现了身份证号码重复的情况,这样如果用身份证号码作为主键也带来了难以处理的情况。当然应对改变,可以有很多解决方案,方案之一是做一新系统与时俱进,这对软件公司来说确实是件好事。

使用逻辑主键的另外一个原因是,业务主键过大,不利于传输、处理和存储。我认为一般如果业务主键超过8字节就应该考虑使用逻辑主键了,因为int是 4字节的,bigint是8字节的,而业务主键一般是字符串,同样是 8 字节的 bigint 和 8 字节的字符串在传输和处理上自然是 bigint 效率更高一些。想象一下 code == "12345678" 和 id == 12345678 的汇编码的不同就知道了。当然逻辑主键不一定是 int 或者 bigint ,而业务主键也不一定是字符串也可以是 int 或 datetime 等类型,同时传输的也不一定就是主键,这个就要具体分析了,但是原理类似,这里只是讨论通常情况。同时如果其他表需要引用该主键的话,也需要存储该主键, 那么这个存储空间的开销也是不一样的。而且这些表的这个引用字段通常就是外键,或者通常也会建索引方便查找,这样也会造成存储空间的开销的不同,这也是需 要具体分析的。

使用逻辑主键的再一个原因是,使用 int 或者 bigint 作为外键进行联接查询,性能会比以字符串作为外键进行联接查询快。原理和上面的类似,这里不再重复。

使用逻辑主键的再一个原因是,存在用户或维护人员误录入数据到业务主键中的问题。例如错把 RMB 录入为 RXB ,相关的引用都是引用了错误的数据,一旦需要修改则非常麻烦。如果使用逻辑主键则问题很好解决,如果使用业务主键则会影响到其他表的外键数据,当然也可以 通过级联更新方式解决,但是不是所有都能级联得了的。

使用业务主键的主要原因是,增加逻辑主键就是增加了一个业务无关的字段,而用户通常都是对于业务相关的字段进行查找(比如员工的工号,书本的 ISBN No. ),这样我们除了为逻辑主键加索引,还必须为这些业务字段加索引,这样数据库的性能就会下降,而且也增加了存储空间的开销。所以对于业务上确实不常改变的 基础数据而言,使用业务主键不失是一个比较好的选择。另一方面,对于基础数据而言,一般的增、删、改都比较少,所以这部分的开销也不会太多,而如果这时候 对于业务逻辑的改变有担忧的话,也是可以考虑使用逻辑主键的,这就需要具体问题具体分析了。

使用业务主键的另外一个原因是,对于用户操作而言,都是通过业务字段进行的,所以在这些情况下,如果使用逻辑主键的话,必须要多做一次映射转换的动 作。我认为这种担心是多余的,直接使用业务主键查询就能得到结果,根本不用管逻辑主键,除非业务主键本身就不唯一。另外,如果在设计的时候就考虑使用逻辑 主键的话,编码的时候也是会以主键为主进行处理的,在系统内部传输、处理和存储都是相同的主键,不存在转换问题。除非现有系统是使用业务主键,要把现有系 统改成使用逻辑主键,这种情况才会存在转换问题。暂时没有想到还有什么场景是存在这样的转换的。

使用业务主键的再一个原因是,对于银行系统而言安全性比性能更加重要,这时候就会考虑使用业务主键,既可以作为主键也可以作为冗余数据,避免因为使 用逻辑主键带来的关联丢失问题。如果由于某种原因导致主表和子表关联关系丢失的话,银行可是会面临无法挽回的损失的。为了杜绝这种情况的发生,业务主键需 要在重要的表中有冗余存在,这种情况最好的处理方式就是直接使用业务主键了。例如身份证号、存折号、卡号等。所以通常银行系统都要求使用业务主键,这个需 求并不是出于性能的考虑而是出于安全性的考虑。

使用复合主键的主要原因和使用业务主键是相关的,通常业务主键只使用一个字段不能解决问题,那就只能使用多个字段了。例如使用姓名字段不够用了,再 加个生日字段。这种使用复合主键方式效率非常低,主要原因和上面对于较大的业务主键的情况类似。另外如果其他表要与该表关联则需要引用复合主键的所有字 段,这就不单纯是性能问题了,还有存储空间的问题了,当然你也可以认为这是合理的数据冗余,方便查询,但是感觉有点得不偿失。

使用复合主键的另外一个原因是,对于关系表来说必须关联两个实体表的主键,才能表示它们之间的关系,那么可以把这两个主键联合组成复合主键即可。如 果两个实体存在多个关系,可以再加一个顺序字段联合组成复合主键,但是这样就会引入业务主键的弊端。当然也可以另外对这个关系表添加一个逻辑主键,避免了 业务主键的弊端,同时也方便其他表对它的引用。

综合来说,网上大多数人是倾向于用逻辑主键的,而对于实体表用复合主键方式的应该没有多少人认同。支持业务主键的人通常有种误解,认为逻辑主键必须对用户来说有意义,其实逻辑主键只是系统内部使用的,对用户来说是无需知道的。

结论或推论:

1、尽量避免使用业务主键,尽量使用逻辑主键。

2、如果要使用业务主键必须保证业务主键相关的业务逻辑改变的概率为0,并且业务主键不太大,并且业务主键不能交由用户修改。

3、除关系表外,尽量不使用复合主键。

使用逻辑主键的最佳实践指南:

1、足够用就好。系统使用的生命周期以100年为限,逻辑主键数据类型采用下表规则,如果不确定则使用int类型。

数据量 数据类型 数据大小 生成频率 备注
< 128 tinyint 1 字节 1条/年 频率过低,不太靠谱,不建议采用
< 3 万 smallint 2 字节 27条/月 频率较低,慎用
< 21 亿 int 4 字节 40条/分钟 能满足大部分情况
< 922 亿亿 bigint 8 字节 292万条/毫秒 能满足绝大部分情况 
>= 922 亿亿 uniqueidentifier 16 字节
100亿用户同时每毫秒生成10亿条,可以连续生成10亿年

可用于分布式、高并发的应用

2、一般采用自增长方式或NewID()方式。

3、主键字段名称一般采用“表名ID”方式,方便识别和表联接。

4、如果表存在分布式应用,则可以考虑采用不同起始值,相同步长方式自增。例如有3个部署在不同地方的库,则可以如下设计:

起始值 步长
1 10
2 10
3 10

步长统一设置10是为了方便日后扩展,这样不同库之间也能保持主键唯一性了,也方便合并。

5、如果存在高并发性需求或数据表迁移需求,可以考虑使用uniqueidentifier类型,并使用NewID()函数。

6、可以考虑对业务主键建立唯一性索引,以实现业务主键唯一性的业务需求。

7、如果需要考虑业务主键的性能需求,可以把业务主键建立聚集索引,而逻辑主键只建立主键约束和非聚集索引即可。

8、关系表可以考虑采用复合主键方式,复合主键不用于实体表。

参考:

关系数据库主键分析
Hibernate开发与实战
数据库主键设计之思考
[讨论]业务主键 Vs. 逻辑主键,到底哪个好?
逻辑主键和联合主键,一定要讨论清楚!
关于在表中设主键的问题
关于在表中设主键的问题

时间: 2024-10-25 11:30:48

MSSQL - 逻辑主键、业务主键和复合主键的相关文章

hibernate 复合主键映射

第一次写博客,只想把工作中遇到的问题记下来. 最近做了一个二次开发的改造,改完之后被告知数据表主键根据需求需要用复合主键,因为本人菜鸟一枚,复合主键从未用过,只能靠度娘 网上给出的复合主键映射大致就两种 第一种:将复合主键对应的属性与实体其他普通属性放在一起 /*实体类.复合主键必须实现Serialzable接口*/ public class User implements Serialzable { private static final long serialVersionUID=1L;/

对逻辑主键、业务主键和复合主键的思考

转载的: http://blog.csdn.net/sunrise918/article/details/5575054 这几天对逻辑主键.业务主键和复合主键进行了一些思考,也在网上搜索了一下相关的讨论,相关讨论可以看最下面的参考链接.下面是自己基于 SQL Server 做的一些总结,其他数据库(Oracle.MySQL.DB2.......)应该也类似吧.这个只是自己一时的思考,如有不当请告知,重新思考后再修 正. ? ? 定义(部分定义来源于 SQL Server 联机丛书): 主键(PR

hibernate复合主键

需要用到实体类Role的主键和Menu的主键结合起来作为实体类RoleMenu的主键,那么通过Hibernate具体实现如下: RoleMenu实体类:(注意该实体类需要实现Serializable接口),且在Hibernate.cfg.xml文件中,复合主键用到的类的映射的xml文件需要放在改类映射的xml文件之前. package com.cdms.model; import java.io.Serializable; /** * 角色权限类 * @author MY * */ public

hibernate中基于主键映射1-1关联关系和基于外键映射1-1关联关系的不同

基于主键映射1-1关联关系和基于外键映射1-1关联关系的不同,主要区别是在配置映射文件上会有区别 两个持久化类为Manager和Department 1:基于主键映射1-1关联关系 1)使用其他持久化类的主键生成主键的实体的映射文件 首先需要指定主键生成方式为foreigner 格式为: <id name="departmentId" type="java.lang.Integer"> <column name="department_i

(九)Hibernate 的复合主键

一.什么是复合主键? 一张表的主键是由多个字段组成,这个主键就被称为复合主键.  主键是唯一确定某条记录的字段,比如公民的身份证号就是一个主键,因为由身份证号这个主键就可以确定 某个公民.   有一种情况,比如学生成绩这张表中,一个学号无法唯一确定这个学生的成绩,因为这个学生有多科成绩,这时候"学号+学科"才是主键,两者结合才能唯一确定一条记录,也就是成绩. 二.hibernate生成含有复合主键表的映射bean 2.1 创建有复合主键的表   这张表有复合主键 2.2 生成映射文件

Hibernate 表映射 主键生成策略与复合主键

主要分析三点: 一.数据表和Java类的映射 : 二.单一主键映射和主键的生成策略 : 三.复合主键的表映射 : 一.数据表和Java类的映射  Hibernate封装了数据库DDL语句,只需要将数据表和类之间实现映射,即可对数据表进行操作. 示例:数据库中存在表interface_admin.ds_area,实现表和类之间映射,其中单一主键oggKeyId,使用主键自动生成策略UUID,具体第二点进行阐述 . package com.pec.model; import java.io.Seri

什么是复合主键

复合主键应该是一张表中,由几个字段来定的唯一性,因为某几列的组合就能唯一确立一条记录,因此他们的组合为一张表的主键.通常,一张表有一个主键字段,是唯一非空的.而复合主键是一张表由几个字段来定唯一性,即每条记录的col1和col2字段唯一. 当一个字段无法确定唯一性的时候,需要其他字段来一起形成唯一性.就是说用来组成唯一性的字段如果有多个就是联合主键如: 学生成绩(学号,课程号,成绩) --那学号和课程号就可以做为联合主键. 因为学号和课程号决定了成绩.也就是说.你要知道成绩..你就要知道学号,知

【Hibernate步步为营】--复合主键映射详解

本题是最基本的分段树操作了.或者一般叫线段树,不过好像和线段没什么关系,只是分段了. 不使用lazy标志,更新只是更新单点. 如果不使用分段树,那么更新时间效率只需要O(1),使用分段树更新效率就需要O(lgn)了. 但是不是用分段树,那么查询的时间效率是O(n),而分段树查询效率是O(lgn) 这就是amortize分摊了时间,而且lgn真的很快,数据不是非常巨大的时候,接近常数了. 故此本题需要使用分段树. #include <cstdio> class EnemyInfo { stati

解决MySQL复合主键下ON DUPLICATE KEY UPDATE语句失效问题

先描述一下这个问题的起因,假设有一张表,里面保存了交易订单,每张订单有唯一的ID,有最后更新时间,还有数据,详情如下: +-------+----------+------+-----+---------------------+-------+ | Field | Type     | Null | Key | Default             | Extra | +-------+----------+------+-----+---------------------+-------