關系型資料庫的幾種常用主鍵-有解無憂

一般來說關系型資料庫，絕大多數表都有資料庫主鍵，

資料庫主鍵的創建，一般有如下幾種形式:

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 table tablename ( colname serial );
//等價于
CREATE SEQUENCE tablename_colname_seq;
CREATE TABLE tablename (
    colname integer 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 TABLE dbo.Globally_Unique_Data
(
    GUID UNIQUEIDENTIFIER
        CONSTRAINT Guid_Default DEFAULT
        NEWSEQUENTIALID() ROWGUIDCOL,
    Employee_Name VARCHAR(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 的代碼示例如下:

    public String 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 TABLE dbo.Department
(
    xxx VARCHAR(10) NOT NULL PRIMARY KEY NONCLUSTERED,
    ...
)
;

然后再加 CLUSTERED INDEX ，來解決此問題，

CREATE CLUSTERED INDEX IX_TestTable_TestCol1   
    ON dbo.TestTable (TestCol1);

當然，如果表的資料量很少，也可以既沒有 CLUSTERED key、也沒有 CLUSTERED index 的，

===============歡迎轉載，轉載請注明出處:https://www.cnblogs.com/jacklondon/

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/105095.html

標籤：PostgreSQL

上一篇：MySQL資料庫：資料的概念

下一篇：MYSQL 匯入dmp檔案失敗，怎么辦