mysql主键有几种_关系型数据库的几种常用主键

一般来说关系型数据库,绝大多数表都有数据库主键。

数据库主键的创建,一般有如下几种形式:

1. 使用数据库自增长主键的语法。

有些数据库,比如 MS SQL Server, MySQL ,都有对应的语法,可以在创建数据库表的时候,指定某个字段为自增长主键。Oracle , PostgreSQL 则使用 sequence , 来达到类似的作用。

以下是 MS SQL Server 示例:

create table tb(id int identity(1,1) primary key );

以下是 PostgreSQL 示例:

//serial 并不是psql的类型,只是一个宏,

create tabletablename ( colname serial );//等价于CREATESEQUENCE tablename_colname_seq;CREATE TABLEtablename (

colnameinteger NOT NULL DEFAULT nextval('tablename_colname_seq')

);ALTER SEQUENCE tablename_colname_seq OWNED BY tablename.colname;

自增长数据库主键,一般是 int/long 之类的整数/长整数。理论上有数据最大容量限制。

在 java/c# 代码中,可将这种主键字段,转换为 long.

2. 使用数据库的 GUID/UUID 之类的语法。

一般是数据字段类型 + 数据库内置函数设置默认值,来定义一个列。

以下是 MS SQL Server 示例:

CREATE TABLEdbo.Globally_Unique_Data

(

GUIDUNIQUEIDENTIFIER

CONSTRAINT Guid_Default DEFAULTNEWSEQUENTIALID()ROWGUIDCOL,

Employee_NameVARCHAR(60)CONSTRAINT Guid_PK PRIMARY KEY(GUID)

);

在 java/c# 代码中,可将这种主键字段,转换为 string.

3. 使用字符串作为表主键,在java/c# 代码中生成 uuid ,填充数值。

以下是 MS SQL Server 示例:

CREATE TABLE [dbo].[tt_process_request]([process_request_uuid] [varchar](40) NOT NULL,

...[created_time] [datetime] NULL,[created_by] [varchar](50) NULL,[updated_time] [datetime] NULL,[updated_by] [varchar](50) NULL,[updated_cnt] [bigint] NULL,CONSTRAINT [PK_tt_process_request] PRIMARY KEY CLUSTERED([process_request_uuid] ASC);

C# 生成 uuid 的代码示例:

string fileUuid = System.Guid.NewGuid().ToString();

Java 生成 uuid 的代码示例如下:

publicString createUuid() {return UUID.randomUUID().toString().replaceAll("-", "");

}

代码生成的 uuid, 中间有 - 分割数据,可以保留,也可以替换/去掉。

4. 使用字符型字段作为数据库表主键,对应某个业务数据。比如合同号: PS21152357。

这类数据中,往往其中的某几位,有一定的业务业务含义,比如,此处 "PS" 为合同号的标识。其它位数,为顺序号。

需要编写 在 java/c# 代码中,来生成这种编号,并做并发防范。

总结:

方法4 , 一般称之为“业务主键”。对应的, 1-3 为“逻辑主键”。

总体而言,应尽量避免使用“业务主键”。因为使用这种主键,有时并非系统自动生成,而是人工录入(比如,数据源头在 ERP,现要在另一个系统中录入数据),人工录入存在一定的出错几率,如果录入出错需要更改主键数据,则外键也要一并更改,往往比较麻烦。

1-3 的三种“逻辑主键”,我更倾向于第三种。

方法3" 使用字符串作为表主键,在java/c# 代码中生成 uuid ,填充数值",不用考虑不同数据库间的差异,可以认为任何数据库都支持。使用起来也简单。

如果是使用自动生成代码工具,要看情况吧。可能有的工具,处理不了。我自己编写的工具,处理起来没问题。

至于 uuid 字段串,占用磁盘空间,比自增长整数/长整数占用的大的问题,其实我觉得并不是大问题。

这不会导致整个系统,磁盘空间需求,增加 1/4 或更多。一般可以忽略。

另,

数据库主键的定义,在某些数据库中,往往会自动带上"按此字段进行顺序存储"之类的语法。比如,SQL Server ,以下是示例:

CREATE TABLE [dbo].[tt_process_request]([process_request_uuid] [varchar](40) NOT NULL,

...,CONSTRAINT [PK_tt_process_request] PRIMARY KEY CLUSTERED([process_request_uuid] ASC)

) ;

这可以通过更改创建表的 SQL, 使用 PRIMARY KEY NONCLUSTERED语法

CREATE TABLEdbo.Department

(

xxxVARCHAR(10) NOT NULL PRIMARY KEY NONCLUSTERED,

...

)

;

然后再加 CLUSTERED INDEX ,来解决此问题。

CREATE CLUSTERED INDEXIX_TestTable_TestCol1ON dbo.TestTable (TestCol1);

当然,数据库表也可以既没有 CLUSTERED key、 也没有 CLUSTERED index 。

这种情况下,表的数据存储,按 insert 的时间顺序,从先到后。大多数情况下,这种数据存放方式,是可以接受的。

数据显示时,再按照某个时间字段(交易数据, 比如销售单的销售时间),或者业务数据主键(主数据/系统配置等),进行查询排序,查询到排序后的数据,显示给用户。

===============欢迎转载,转载请注明出处:https://www.cnblogs.com/jacklondon/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值