关于主键的设计、primary key

主键:用于唯一标识一个表中一行数据。

外键:用于建立两个表之间的关系,A表中有一列是B表中的主键,那么A表中这列的数据就受到B表主键的约束。

那么关于主键应该如何设计呢,这里我说下优缺点:

1.用自动增长字段作为主键,这样的主键可以称之为 非业务主键(或逻辑主键、或代理主键),就是说这列与业务无关,仅仅是作为主键而设计。

优点:自增长字段往往是integer bigint类型,最多占8个字节。索引与外键 所占用的空间连带减少,增删改查 效率高。业务变化,不影响,不需要更新主键。

缺点:无法转移数据库,比如把表中的一批数据 转移 或 附带到 另一个表中,那么由于是自增长字段,那么会导致无法转移,因为另外一个表可能已经存在部分数据,会造成主键冲突。自增长字段的缺陷。

业务数据的完整性,无法保证。

2.用全球唯一标识符GUID,来做主键。依然是非业务主键。

优点:可以转移数据库。业务变化,不影响,不需要更新主键。

缺点:字符串较长,占用的空间较多,如果用于外键的话,会导致连带其它表占用的空间连带增多。A表中有一列是B表中的主键 ,那么A表中的这列也是需要有个索引的,即存储空间会连带增多。效率变低。

即除了正常业务字段外,还是弄个字符串字段来专一保存这个全球唯一标识符,造成存储浪费。业务数据的完整性,无法保证。

3.用业务字段做主键。

优点:可以转移数据库,最大化节省了空间,因为并没有 多增加一个非业务字段做主键。业务数据的完整性,可以保证。避免产生垃圾数据,银行就是用业务字段做主键的,虽然效率低,但是安全。

缺点:如果业务发生改变,有可能需要修改主键,举例:国家A表用身份证号做主键,然后其他很多表中的身份证号这列都是来自 身份证表A中的主键(即外键),那么如果身份证号升级,比如从1代升级到2代,那么

那么连带的表的外键 的索引 通通都得发生变化,效率极低 因为会连带更新一串用到这个外键的表,可见用业务字段做主键的话,你得保证 主键不经常变化。

==============

综上:用哪种方式做主键,还是得看业务需求,实际情况,实事求是。根据情况选择,没有固定的标准。

时间: 2024-11-08 04:40:13

关于主键的设计、primary key的相关文章

数据库模型设计——关系的实现,主键的设计

一.关系的实现 在实体关系模型中,我们知道有三种关系:一对一.一对多.多对多.这只是概念上的关系,但是在真实的关系数据库中,我们只有外键,并没有这三种关系,那么我们就来说一说在关系数据库管理系统中,怎么实现这三种关系. 一对多 这里先讲解一对多,因为这个关系最简单.一对多和多对一是一回事,所以就不再提多对一这个词.一对多的概念是一个对象A会对应多个对象B,而从B的角度看,一个对象B只会对于一个对象A.比如说班级和学生就是一对多关系.一个班级对应多个学生,一个学生只会对于一个班级. 一对多的关系之

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

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

MongoDB学习笔记~ObjectId主键的设计

说一些关于ObjectId的事 MongoDB确实是最像关系型数据库的NoSQL,这在它主键设计上可以体现的出来,它并没有采用自动增长主键,因为在分布式服务器之间做数据同步很麻烦,而是采用了一种ObjectId的方式,它生成方便,占用空间比long多了4个字节,(12个字节)在数据表现层面也说的过去,它是一种以时间,机器,进程和自增几个因素组合的方式来体现的,可以近似看成是按时间的先后进行排序的,对于ObjectId的生成我们可以通过MongoDB服务端去获得,或者在客户端也有对它的集成,使用方

数据表中的主键

----还在加班中 再过3个小时就清明节了.我的这块任务以完成咱们聊聊主键 主键 在表的设计中一般都会有一个主键.主键的作用是为了有效的管理表中的数据,主键的存在做为唯一的标识列,主键的存在将表中的每一行数据区分开来,方便有效的检索,更新,删除, 如果没有主键我们执行这些功能时效率将会缓慢. 主键作为标识符,在表中是不具有描述性的(描述性:指有特定的含义 比如 ProjectName:项目名称),主键一般来说是数值类型,并且不用具有描述性而且唯一的字段(比如:社保卡号,手机号码等...) 我们从

PHP数据连接主键与外键!

设置MySQL数据表主键: 使用"primary key"关键字创建主键数据列.被设置为主键列不允许出现重复的值,很多情况下与"auto_increment"递增数字相结合.如下SQL语句所示: Mysql>create table books(bookid int(11) NOT NULL AUTO_INCREMENT PRIMARY KEY,bookname varchar(50)); Mysql>insert into books(bookname

定义主键

通过主键能够唯一定位一条数据记录,而且在进行外键关联的时候也需要被关联的数据表具有主键,所以为数据表定义主键是非常好的习惯.在CREATE TABLE 中定义主键是通过PRIMARY KEY 关键字来进行的,定义的位置是在所有字段定义之后.比如我们为公交车建立一张数据表,这张表中有公交车编号FNumber.驾驶员姓名FDriverName.投入使用年数FUsedYears等字段,其中公交车编号FNumber 字段要定义为主键,那么只要如下设计建表SQL: MYSQL,MSSQLServer: C

SQL PRIMARY KEY 约束\SQL FOREIGN KEY 约束\SQL CHECK 约束

SQL PRIMARY KEY 约束 PRIMARY KEY 约束唯一标识数据库表中的每条记录. 主键必须包含唯一的值. 主键列不能包含 NULL 值. 每个表都应该有一个主键,并且每个表只能有一个主键. SQL PRIMARY KEY Constraint on CREATE TABLE 下面的 SQL 在 "Persons" 表创建时在 "Id_P" 列创建 PRIMARY KEY 约束: MySQL: CREATE TABLE Persons ( Id_P i

MySQL 主键外键

笛卡儿积 多表查询 ,多个表变成一个表 完整性约束条件primary key    标识该属性为该表的主键,可以唯一的标识对应的元组foreign key    标识该属性为该表的外键,是与之联系的某表的主键not null       标识该属性不能为空unique         标识该属性的值是唯一的auto_increment 标识该属性的值自动增加default        为该属性设置默认值设置从表 外键constraint 外键别名 foreign key(属性1.1, 属性1.

MySQL主键设计盘点

目录 主键定义 主键设计和应用原则 主键生成策略 自增ID UUID 自建的id生成器 Twitter的snowflake算法 @ 最近在项目中用了UUID的方式生成主键,一开始只是想把这种UUID的方式生成主键记录下来,在查阅资料的过程中,又有了一些新的认识和思考. 主键定义 唯一标识表中每行的一个列(或一组列)称为主键.主键用来表示一个特定的行. 主键设计和应用原则 除了满足MySQL强制实施的规则(主键不可重复:一行中主键不可为空)之外,主键的设计和应用应当还遵守以下公认的原则: 不更新主