應用系統爲需要創建自增列的表創建一個序列名稱，在表“T_DB_SEQ”中反映爲數據庫中的一行。
第一，需要爲需要建立序列的表創建一個序列。採用方法：F_create_SEQ(序列名)。該函數傳入序列的名稱，在表“T_DB_SEQ”插入一行。序列的所有者，採用系統變量SYSTEM_USER。
第二，獲取下一個值。採用方法：F_GET_NEXT_SEQ_VAL(序列名)。該函數根據序列名獲取該序列的下一個值，根據當前值與增長步長得到。同時，該函數保證在同時獲取同一個序列時，應保證併發一致性。
第三、將返回值返回到應用使用。
此外，爲保證應用的完整性，可能還需要提供一些方法的重載方法，同時提供一些其他方法：
獲取序列當前值：F_GET_SEQ_CUR_VAL(序列名)
設置序列值：F_SET_SEQ_VAL(序列名)
刪除序列：F_DEL_SEQ(序列名)
判斷序列是否存在：F_SEQ_exists(序列名)
在主從關係的表設計中，子表也使用序列字段作爲唯一主鍵，將父表的序列字段作爲外鍵關聯：
以下爲引用的內容：
create TABLE T_PK_DEMO_C
(
U_ID BIGINT NOT NULL ,--唯一標識記錄的ID
COL_OTHER VARchar(20) NOT NULL ,--其他列
P_ID INT NOT NULL ,--父表ID
CONSTRAINT PK_T_PK_DEMO_C PRIMARY KEY
NONCLUSTERED (U_ID)--定義爲主鍵
CONSTRAINT FK_T_PK_DEMO_C FOREIGN KEY (P_ID)
REFERENCES T_PK_DEMO(U_ID) ON delete CASCADE,
)
使用序列的問題及解決辦法
由於系統使用一個額外增加一個字段作爲主鍵，因此沒有爲業務邏輯建立主鍵約束。比如在企業用戶信息表中，要求企業中用戶登錄名必須唯一。一般在創建表時，以登錄名作爲主鍵，這個時候在數據庫層自然的創建另一個主鍵唯一性約束。而現在沒有使用登錄名作爲主鍵，那麼就沒有這個約束。解決辦法：
一是在數據庫層解決。可以爲該表創建一個唯一(UNIQUE)約束或者唯一索引。如：
alter TABLE T_PK_DEMO ADD CONSTRAINT C_T_PK_DEMO UNIQUE NONCLUSTERED(COL_OTHER)-唯一約束
create UNIQUE INDEX IX_T_PK_DEMO ON T_PK_DEMO(COL_OTHER) – 唯一索引
二是在應用端解決。也就是在應用中判斷該列是否有重複值，然後根據判斷結果來保證唯一性。
我們注意到，在之前的例子中，主鍵採用了NONCLUSTERED(非聚蔟)的索引方式。關於如何設計索引，不是本文的重點，在這裏僅提供一個建立索引時採用聚蔟方式還是非聚蔟方式的一個一般原則：
作爲非業務字段的主鍵列，是一個沒有重複值的、基本不進行更新操作的列。並且，在SQL Server數據庫中，聚蔟索引在一個表中只能有一個。因此，聚蔟索引非常重要，需要留給更重要的字段來使用。因此，對照上表和根據聚蔟索引的重要程度，在此處採用非聚蔟方式創建其索引。
具體應用
參加sql server 2005培訓據講師介紹採用這種主鍵設計方式，有諸多好處，這已經在前文說明。現在就以一個具體的應用來說明如何使用這個主鍵。
當前的應用系統基本上都已經採用B/S方式，儘管現在的網絡速度已經有大幅度的提高，但是由於在WEB應用上用戶數量衆多、同時基本上所有的運算都集中在WEB應用服務器上，所以在WEB設計上更要考慮到性能的優化，以減少網絡流量和對服務器的壓力。最常見的一個應用就是列表方式展現時的分頁方式。一般的，在數據量小的情況下，一般不會怎麼注意這個問題，通常採用將數據完全取出，然後在WEB服務器上進行分頁。但是，當數據量龐大時，這種方式就會導致速度降低，甚至根本不可用。所以，一般採用存儲過程，在數據庫端進行分頁。
一個C/S架構的程序，突然登錄時提示無法鏈接數據庫了，經測試發現是IP的原因，就是說用192.168.114.45這個IP連不上數據庫，而用192.168.114.46、192.168.114.44都可以，有的說是被數據庫鎖定IP了，但是應該在哪裏調整呢？請高手指點一下！
在SQL Server數據庫中，聚蔟索引在一個表中只能有一個
數據庫本身沒有什麼鎖定的說法
1 問問你們網管有沒有調整過防火牆,或者ip sec策略
2 另外你的這麼多ip都是指sqlserver所在的服務器還是用戶端,如果是服務器端的話那還要去查網絡的問題
來源：英超直播
-------在oracle數據庫中的聚蔟索引在一個表也只能有一個
------->根據聚蔟索引的意義，應該是在什麼數據庫中一個表也只能有一個聚蔟索引