1) assigned
主鍵由外部程式負責產生,無需Hibernate參與。
2) hilo
通過hi/lo 演算法實現的主鍵產生機制,需要額外的資料庫表儲存主
鍵產生曆史狀態。
3) seqhilo
與hilo 類似,通過hi/lo 演算法實現的主鍵產生機制,只是主鍵曆史
狀態儲存在Sequence中,適用於支援Sequence的資料庫,如Oracle。
4) increment
主鍵按數值順序遞增。此方式的實現機製為在當前應用執行個體中維持
一個變數,以儲存著當前的最大值,之後每次需要產生主鍵的時候
將此值加1作為主鍵。
這種方式可能產生的問題是:如果當前有多個執行個體訪問同一個資料
庫,那麼由於各個執行個體各自維護主鍵狀態,不同執行個體可能產生同樣
的主鍵,從而造成主鍵重複異常。因此,如果同一資料庫有多個實
例訪問,此方式必須避免使用。
5) identity
採用資料庫提供的主鍵產生機制。如DB2、SQL Server、MySQL
中的主鍵產生機制。
6) sequence
採用資料庫提供的sequence 機制產生主鍵。如Oralce 中的
Sequence。
7) native
由Hibernate根據底層資料庫自行判斷採用identity、hilo、sequence
其中一種作為主鍵產生方式。
8) uuid.hex
由Hibernate基於128 位唯一值產生演算法產生16 進位數值(編碼後
以長度32 的字串表示)作為主鍵。
9) uuid.string
與uuid.hex 類似,只是產生的主鍵未進行編碼(長度16)。在某些
資料庫中可能出現問題(如PostgreSQL)。
10) foreign
使用外部表格的欄位作為主鍵。
一般而言,利用uuid.hex方式產生主鍵將提供最好的效能和資料庫平台適
應性。
另外由於常用的資料庫,如Oracle、DB2、SQLServer、MySql 等,都提
供了易用的主鍵產生機制(Auto-Increase 欄位或者Sequence)。我們可以在數
據庫提供的主鍵產生機制上,採用generator-class=native的主鍵產生方式。
不過值得注意的是,一些資料庫提供的主鍵產生機制在效率上未必最佳,
大量並發insert資料時可能會引起表之間的互鎖。
資料庫提供的主鍵產生機制,往往是通過在一個內部表中儲存當前主鍵狀
態(如對於自增型主鍵而言,此內部表中就維護著當前的最大值和遞增量),
之後每次插入資料會讀取這個最大值,然後加上遞增量作為新記錄的主鍵,之
後再把這個新的最大值更新回內部表中,這樣,一次Insert操作可能導致資料
庫內部多次表讀寫操作,同時伴隨的還有資料的加鎖解鎖操作,這對效能產生
了較大影響。
因此,對於並發Insert要求較高的系統,推薦採用uuid.hex 作為主鍵產生
機制。
CREATE OR REPLACE TRIGGER tib_report
BEFORE INSERT
ON SMS_REPORT
FOR EACH ROW
DECLARE integrity_error EXCEPTION; errno INTEGER; errmsg CHAR(200); dummy INTEGER; FOUND BOOLEAN;
BEGIN
-- Column "ID" uses sequence booking_seq
SELECT SMS_REPORT_SEQ.NEXTVAL INTO :NEW.RPT_ID FROM dual;
-- Errors handling
EXCEPTION
WHEN
integrity_error THEN RAISE_APPLICATION_ERROR(errno, errmsg); END;