sqlserver數(shù)據(jù)庫主鍵的生成方式小結(sqlserver,mysql)
更新時間：2012年07月27日 09:21:46 作者：
嚴格講這三種產(chǎn)生方式有一定的交叉點，其定位方式將在下面進行講解
主鍵的生成方式主要有三種：
一. 數(shù)據(jù)庫自動生成
二. GUID
三. 開發(fā)創(chuàng)建
嚴格講這三種產(chǎn)生方式有一定的交叉點，其定位方式將在下面進行講解。
第一種方式，主要將其定位在自增長的標識種子：可以設置起始數(shù)值，及增長步長。其優(yōu)點在于使用時完全將并發(fā)任務交于數(shù)據(jù)庫引擎管理，你不用擔心存在多用戶使用的時候會產(chǎn)生兩個相同的ID的情況。其缺點也在于此，多數(shù)的數(shù)據(jù)庫不提供直接獲取標識ID的方式，對于開發(fā)人員來說產(chǎn)生ID的方式是透明的，開發(fā)人員幾乎無法干預此項。對于數(shù)據(jù)的遷移也不是很方便。
由于存在上面的利弊，這種自增長的ID一般多用于設計基礎表（系統(tǒng)運行的基礎信息，如員工表）主鍵，而極少（根本不）用于主從表主、外鍵，因為在產(chǎn)生主從表數(shù)據(jù)并關聯(lián)時，必須確定主表的ID，然后才能定位從表的關聯(lián)ID。
例(MsSQL):
--創(chuàng)建測試表
CREATE TABLE [Identity](
Id INT IDENTITY(1,2) NOT NULL PRIMARY KEY,--種子的起始值1，步長2
Number VARCHAR(20) UNIQUE NOT NULL,
Name VARCHAR(20) NOT NULL,
Password VARCHAR(20) DEFAULT(123),
Description VARCHAR(40) NULL
)
--插入記錄
INSERT INTO [Identity](Number,Name,Description) VALUES('001','1st','Id=1,因為起始值1')
INSERT INTO [Identity](Number,Name,Description) VALUES('002','2nd','Id=3,因為起始值1，步長2')
INSERT INTO [Identity](Number,Name,Description) VALUES('003','3rd','Id=5,由于字符長度超長，報錯插入失敗，造成此Id產(chǎn)生后被放棄')
INSERT INTO [Identity](Number,Name,Description) VALUES('004','4th','Id=7 not 5,因為第三條記錄插入失敗')
--檢索記錄，查看結果
SELECT * FROM [Identity]
結果：
(1 行受影響)
(1 行受影響)
消息 8152，級別 16，狀態(tài) 14，第 3 行
將截斷字符串或二進制數(shù)據(jù)。
語句已終止。
(1 行受影響)
(3 行受影響)
Id Number Name Password Description
1 001 1st 123 Id=1,因為起始值1
3 002 2nd 123 Id=3,因為起始值1，步長2
7 004 4th 123 Id=7 not 5,因為第三條記錄插入失敗
第二種方式，GUID即Globally Unique Identifier，也稱為UUID（Universally Unique IDentifier），全球唯一標識符，GUID一般由32位十六進制的數(shù)值組成，其中包含網(wǎng)卡地址、時間及其他信息。任何兩臺電腦都不會產(chǎn)生相同的GUID，他的優(yōu)點在唯一性，當需要數(shù)據(jù)庫整合時，能節(jié)約不少勞動力。比如總公司和分公司各自系統(tǒng)獨立運行，所有分公司數(shù)據(jù)定期需要提交到總部，可以避免合并數(shù)據(jù)時主鍵沖突問題，同時GUID還兼具自增長標識種子特點，無需開發(fā)人員太多的關注。但是GUID信息量大，占用空間也大，關聯(lián)檢索時，估計效率上也不是很高，對于32位的十六進制其可讀性也差，雖然主鍵有對用戶的無意義性，但是在設計或者調(diào)試交流時很不方便。
從長遠考慮，為了保證數(shù)據(jù)的可移植性，一般還是會選擇使用GUID來作為主鍵。
例(MsSQL):
--創(chuàng)建測試表
CREATE TABLE GUID(
Id UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,--當然你也可以用字符串來保存
Number VARCHAR(20) UNIQUE NOT NULL,
Name VARCHAR(20) NOT NULL,
Password VARCHAR(20) DEFAULT(123)
)
--插入記錄
INSERT INTO GUID(Id,Number,Name) VALUES(NewID(),'001','1st')
INSERT INTO GUID(Id,Number,Name) VALUES(NewID(),'002','2nd')
INSERT INTO GUID(Id,Number,Name) VALUES(NewID(),'003','3rd')
--檢索記錄，查看結果
SELECT * FROM GUID
結果：
Id Number Name Password
8E194F55-B4D3-4C85-8667-33BC6CD33BBC 001 1st 123
7141F202-7D0E-4992-9164-5043EC9FC6F6 002 2nd 123
E0E365A0-8748-4656-AF24-5D0B216D2095 003 3rd 123
第三種方式開發(fā)創(chuàng)建，其便捷性在于可控制性，此可控制性是指其組成形式，可以是整形、也可以是字符型，你可以根據(jù)實際情況給予多樣的組成及產(chǎn)生形式，說到這里可能有的朋友就想起來自動產(chǎn)生單號，如：20120716001或者PI-201207-0001等等，沒錯，自我創(chuàng)建同樣適用于這些類似的應用。
說到自我創(chuàng)建，多數(shù)首先想到的是取Max(Id)+1，這種方式雖然省事，但是實際上對于定制（在生產(chǎn)單號之類的有一定意義的信息時可能會有這樣的需求，主鍵沒必要）及并發(fā)的處理并不是很好。如，當前表中最大編號為1000，當C1和C2用戶同時取這個Id處理時，得到的都是1001，導致保存失敗。常規(guī)的做法是在取值時候加鎖，但是當多用戶頻繁操作時，性能是個很大的問題，其中主要的原因之一是直接操作的業(yè)務數(shù)據(jù)表。
針對此種情況，解決方案是使用鍵值表來保存表名、當前或者下一個Id及其他信息，如果系統(tǒng)中多個表Id都使用這種方式，那么鍵值表中就會有多條相應的規(guī)則記錄；當然也可以讓整個數(shù)據(jù)庫所有表的Id從都按相同的規(guī)則從一個源產(chǎn)生，那么鍵值表中只需要一條規(guī)則記錄即可。
下面來看看這樣一個使用鍵值表例子的演變(MsSQL):
--創(chuàng)建鍵值表
CREATE TABLE KeyTable(
ID INT IDENTITY(1,1) PRIMARY KEY NOT NULL,
TCode VARCHAR(20) UNIQUE NOT NULL,
TName VARCHAR(50) NOT NULL,
TKey INT NOT NULL,
)
GO
--插入測試記錄
INSERT INTO KeyTable(TCode,TName,TKey)
VALUES('T001','Test',0)
GO
--創(chuàng)建獲取指定表ID的存儲過程，也可以修改成函數(shù)
CREATE PROCEDURE UP_NewTableID
@TCode VARCHAR(20),@NextID INT OUTPUT
AS
DECLARE @CurTKey INT,@NextTKey INT
BEGIN TRAN TransID
SELECT @CurTKey=TKey
FROM KeyTable
WHERE TCode = @TCode
IF @@ROWCOUNT = 0
BEGIN
ROLLBACK TRAN TransID
RAISERROR('Warning: No such row is exists',16,1)
RETURN
END
SET @NextTKey = @CurTKey + 1
--WAITFOR DELAY '00:00:05'
UPDATE KeyTable
SET TKey = @NextTKey
WHERE TCode = @TCode
IF @@ROWCOUNT = 0
BEGIN
ROLLBACK TRAN TransID
RAISERROR('Warning: No such row is updated',16,1)
RETURN
END
COMMIT TRAN TransID
SET @NextID = @NextTKey
GO
執(zhí)行存儲過程UP_NewTableID:
DECLARE @NextID INT
EXEC UP_NewTableID 'T001',@NextID OUTPUT
PRINT @NextID
運行的時會發(fā)現(xiàn)很正常，獲取的結果也很正確。但是如果在高并發(fā)的情況，多個用戶可能就會獲取相同的ID，如果獲取的ID后是用于保存對應表中的記錄，那么最多只有一個用戶能保存成功。
下面模擬一下并發(fā)情形，將上面的存儲過程UP_NewTableID中語句WAITFOR DELAY '00:00:05'的注釋去掉，打開3個查詢分析器的窗體，依次執(zhí)行上面語句。
預期是想分別獲得1,2,3，但是也許會發(fā)現(xiàn)多個窗體的運行結果都是：1。這就是說在更新語句執(zhí)行之前，大家都獲取的ID是0，所以下一個數(shù)值都是為1。（實際的數(shù)值，根據(jù)DELAY的參數(shù)大小及運行時間按間隔有關）
從這方面來分析的話有的朋友可能就會想到，是否可以在更新語句執(zhí)行時判斷ID是不是原始ID了？修改過程：
ALTER PROCEDURE UP_NewTableID
@TCode VARCHAR(20),@NextID INT OUTPUT
AS
DECLARE @CurTKey INT,@NextTKey INT
BEGIN TRAN TransID
SELECT @CurTKey=TKey
FROM KeyTable
WHERE TCode=@TCode
IF @@ROWCOUNT=0BEGIN
ROLLBACK TRAN TransID
RAISERROR('Warning: No such row is exists',16,1)
RETURN
END
SET @NextTKey=@CurTKey+1
WAITFOR DELAY '00:00:05'
UPDATE KeyTable
SET TKey=@NextTKey
WHERE TCode=@TCode AND TKey=@CurTKey--此處加上TKey的校驗
IF @@ROWCOUNT=0BEGIN
ROLLBACK TRAN TransID
RAISERROR('Warning: No such row is updated',16,1)
RETURN
END
COMMIT TRAN TransID
SET @NextID=@NextTKey
GO
如果打開個3個執(zhí)行過程來模擬并發(fā)，那么會有2個窗體出現(xiàn)：
消息 50000，級別 16，狀態(tài) 1，過程 UP_NewTableID，第 28 行
Warning: No such row is updated
由此會看到還是會由于并發(fā)導致有用戶操作失敗，但是較上一個至少將錯誤出現(xiàn)的時間點提前了。
那么有沒有更好的方法，從查詢到更新結束整個事務過程中，不會有任何其他事務插入其中來攪局的辦法呢，答案很明確，有，使用鎖！需要選擇適當?shù)逆i，否則效果將和上面的一樣。
ALTER PROCEDURE UP_NewTableID
@TCode VARCHAR(20),@NextID INT OUTPUT
AS
DECLARE @CurTKey INT,@NextTKey INT
BEGIN TRAN TransID
SELECT @CurTKey=TKey
FROM KeyTable WITH (UPDLOCK)--采用更新鎖，并保持到事務完成
WHERE TCode=@TCode
IF @@ROWCOUNT=0BEGIN
ROLLBACK TRAN TransID
RAISERROR('Warning: No such row is exists',16,1)
RETURN
END
SET @NextTKey=@CurTKey+1
WAITFOR DELAY '00:00:05'
UPDATE KeyTable
SET TKey=@NextTKey
WHERE TCode=@TCode--此處無需驗證TKey是否與SELECT的相同
COMMIT TRAN TransID
SET @NextID=@NextTKey
GO
可以打開N（N>=2)個窗體來進行測試，將會看到所有操作都被串行化，結果就是我們想要的那樣。如此注釋或者去掉模仿并發(fā)的語句WAITFOR DELAY '00:00:05'即可。
如前面所說，這同樣適應于單據(jù)編號類似編碼的產(chǎn)生形式，只要對前面的代碼及鍵值表稍作修改即可，有興趣的朋友可以一試。如果是從前端取得這個編號，并應用于各個記錄，那么可能存在跳號的可能。如果為了保證不存在跳號，一種解決方案就是使用跳號表，將跳號記錄定期掃描并應用于其他記錄。另一種解決方案是將記錄的保存操作放置到編號產(chǎn)生的過程中，形成一個串行化的事務。
俗話說蘿卜白菜各有所愛，您用哪一種自有你的道理。
一. 數(shù)據(jù)庫自動生成
二. GUID
三. 開發(fā)創(chuàng)建
嚴格講這三種產(chǎn)生方式有一定的交叉點，其定位方式將在下面進行講解。
第一種方式，主要將其定位在自增長的標識種子：可以設置起始數(shù)值，及增長步長。其優(yōu)點在于使用時完全將并發(fā)任務交于數(shù)據(jù)庫引擎管理，你不用擔心存在多用戶使用的時候會產(chǎn)生兩個相同的ID的情況。其缺點也在于此，多數(shù)的數(shù)據(jù)庫不提供直接獲取標識ID的方式，對于開發(fā)人員來說產(chǎn)生ID的方式是透明的，開發(fā)人員幾乎無法干預此項。對于數(shù)據(jù)的遷移也不是很方便。
由于存在上面的利弊，這種自增長的ID一般多用于設計基礎表（系統(tǒng)運行的基礎信息，如員工表）主鍵，而極少（根本不）用于主從表主、外鍵，因為在產(chǎn)生主從表數(shù)據(jù)并關聯(lián)時，必須確定主表的ID，然后才能定位從表的關聯(lián)ID。
例(MsSQL):
復制代碼 代碼如下:
--創(chuàng)建測試表
CREATE TABLE [Identity](
Id INT IDENTITY(1,2) NOT NULL PRIMARY KEY,--種子的起始值1，步長2
Number VARCHAR(20) UNIQUE NOT NULL,
Name VARCHAR(20) NOT NULL,
Password VARCHAR(20) DEFAULT(123),
Description VARCHAR(40) NULL
)
--插入記錄
INSERT INTO [Identity](Number,Name,Description) VALUES('001','1st','Id=1,因為起始值1')
INSERT INTO [Identity](Number,Name,Description) VALUES('002','2nd','Id=3,因為起始值1，步長2')
INSERT INTO [Identity](Number,Name,Description) VALUES('003','3rd','Id=5,由于字符長度超長，報錯插入失敗，造成此Id產(chǎn)生后被放棄')
INSERT INTO [Identity](Number,Name,Description) VALUES('004','4th','Id=7 not 5,因為第三條記錄插入失敗')
--檢索記錄，查看結果
SELECT * FROM [Identity]
結果：
(1 行受影響)
(1 行受影響)
消息 8152，級別 16，狀態(tài) 14，第 3 行
將截斷字符串或二進制數(shù)據(jù)。
語句已終止。
(1 行受影響)
(3 行受影響)
Id Number Name Password Description
1 001 1st 123 Id=1,因為起始值1
3 002 2nd 123 Id=3,因為起始值1，步長2
7 004 4th 123 Id=7 not 5,因為第三條記錄插入失敗
第二種方式，GUID即Globally Unique Identifier，也稱為UUID（Universally Unique IDentifier），全球唯一標識符，GUID一般由32位十六進制的數(shù)值組成，其中包含網(wǎng)卡地址、時間及其他信息。任何兩臺電腦都不會產(chǎn)生相同的GUID，他的優(yōu)點在唯一性，當需要數(shù)據(jù)庫整合時，能節(jié)約不少勞動力。比如總公司和分公司各自系統(tǒng)獨立運行，所有分公司數(shù)據(jù)定期需要提交到總部，可以避免合并數(shù)據(jù)時主鍵沖突問題，同時GUID還兼具自增長標識種子特點，無需開發(fā)人員太多的關注。但是GUID信息量大，占用空間也大，關聯(lián)檢索時，估計效率上也不是很高，對于32位的十六進制其可讀性也差，雖然主鍵有對用戶的無意義性，但是在設計或者調(diào)試交流時很不方便。
從長遠考慮，為了保證數(shù)據(jù)的可移植性，一般還是會選擇使用GUID來作為主鍵。
例(MsSQL):
復制代碼 代碼如下:
--創(chuàng)建測試表
CREATE TABLE GUID(
Id UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,--當然你也可以用字符串來保存
Number VARCHAR(20) UNIQUE NOT NULL,
Name VARCHAR(20) NOT NULL,
Password VARCHAR(20) DEFAULT(123)
)
--插入記錄
INSERT INTO GUID(Id,Number,Name) VALUES(NewID(),'001','1st')
INSERT INTO GUID(Id,Number,Name) VALUES(NewID(),'002','2nd')
INSERT INTO GUID(Id,Number,Name) VALUES(NewID(),'003','3rd')
--檢索記錄，查看結果
SELECT * FROM GUID
結果：
Id Number Name Password
8E194F55-B4D3-4C85-8667-33BC6CD33BBC 001 1st 123
7141F202-7D0E-4992-9164-5043EC9FC6F6 002 2nd 123
E0E365A0-8748-4656-AF24-5D0B216D2095 003 3rd 123
第三種方式開發(fā)創(chuàng)建，其便捷性在于可控制性，此可控制性是指其組成形式，可以是整形、也可以是字符型，你可以根據(jù)實際情況給予多樣的組成及產(chǎn)生形式，說到這里可能有的朋友就想起來自動產(chǎn)生單號，如：20120716001或者PI-201207-0001等等，沒錯，自我創(chuàng)建同樣適用于這些類似的應用。
說到自我創(chuàng)建，多數(shù)首先想到的是取Max(Id)+1，這種方式雖然省事，但是實際上對于定制（在生產(chǎn)單號之類的有一定意義的信息時可能會有這樣的需求，主鍵沒必要）及并發(fā)的處理并不是很好。如，當前表中最大編號為1000，當C1和C2用戶同時取這個Id處理時，得到的都是1001，導致保存失敗。常規(guī)的做法是在取值時候加鎖，但是當多用戶頻繁操作時，性能是個很大的問題，其中主要的原因之一是直接操作的業(yè)務數(shù)據(jù)表。
針對此種情況，解決方案是使用鍵值表來保存表名、當前或者下一個Id及其他信息，如果系統(tǒng)中多個表Id都使用這種方式，那么鍵值表中就會有多條相應的規(guī)則記錄；當然也可以讓整個數(shù)據(jù)庫所有表的Id從都按相同的規(guī)則從一個源產(chǎn)生，那么鍵值表中只需要一條規(guī)則記錄即可。
下面來看看這樣一個使用鍵值表例子的演變(MsSQL):
復制代碼 代碼如下:
--創(chuàng)建鍵值表
CREATE TABLE KeyTable(
ID INT IDENTITY(1,1) PRIMARY KEY NOT NULL,
TCode VARCHAR(20) UNIQUE NOT NULL,
TName VARCHAR(50) NOT NULL,
TKey INT NOT NULL,
)
GO
--插入測試記錄
INSERT INTO KeyTable(TCode,TName,TKey)
VALUES('T001','Test',0)
GO
--創(chuàng)建獲取指定表ID的存儲過程，也可以修改成函數(shù)
CREATE PROCEDURE UP_NewTableID
@TCode VARCHAR(20),@NextID INT OUTPUT
AS
DECLARE @CurTKey INT,@NextTKey INT
BEGIN TRAN TransID
SELECT @CurTKey=TKey
FROM KeyTable
WHERE TCode = @TCode
IF @@ROWCOUNT = 0
BEGIN
ROLLBACK TRAN TransID
RAISERROR('Warning: No such row is exists',16,1)
RETURN
END
SET @NextTKey = @CurTKey + 1
--WAITFOR DELAY '00:00:05'
UPDATE KeyTable
SET TKey = @NextTKey
WHERE TCode = @TCode
IF @@ROWCOUNT = 0
BEGIN
ROLLBACK TRAN TransID
RAISERROR('Warning: No such row is updated',16,1)
RETURN
END
COMMIT TRAN TransID
SET @NextID = @NextTKey
GO
執(zhí)行存儲過程UP_NewTableID:
復制代碼 代碼如下:
DECLARE @NextID INT
EXEC UP_NewTableID 'T001',@NextID OUTPUT
PRINT @NextID
運行的時會發(fā)現(xiàn)很正常，獲取的結果也很正確。但是如果在高并發(fā)的情況，多個用戶可能就會獲取相同的ID，如果獲取的ID后是用于保存對應表中的記錄，那么最多只有一個用戶能保存成功。
下面模擬一下并發(fā)情形，將上面的存儲過程UP_NewTableID中語句WAITFOR DELAY '00:00:05'的注釋去掉，打開3個查詢分析器的窗體，依次執(zhí)行上面語句。
預期是想分別獲得1,2,3，但是也許會發(fā)現(xiàn)多個窗體的運行結果都是：1。這就是說在更新語句執(zhí)行之前，大家都獲取的ID是0，所以下一個數(shù)值都是為1。（實際的數(shù)值，根據(jù)DELAY的參數(shù)大小及運行時間按間隔有關）
從這方面來分析的話有的朋友可能就會想到，是否可以在更新語句執(zhí)行時判斷ID是不是原始ID了？修改過程：
復制代碼 代碼如下:
ALTER PROCEDURE UP_NewTableID
@TCode VARCHAR(20),@NextID INT OUTPUT
AS
DECLARE @CurTKey INT,@NextTKey INT
BEGIN TRAN TransID
SELECT @CurTKey=TKey
FROM KeyTable
WHERE TCode=@TCode
IF @@ROWCOUNT=0BEGIN
ROLLBACK TRAN TransID
RAISERROR('Warning: No such row is exists',16,1)
RETURN
END
SET @NextTKey=@CurTKey+1
WAITFOR DELAY '00:00:05'
UPDATE KeyTable
SET TKey=@NextTKey
WHERE TCode=@TCode AND TKey=@CurTKey--此處加上TKey的校驗
IF @@ROWCOUNT=0BEGIN
ROLLBACK TRAN TransID
RAISERROR('Warning: No such row is updated',16,1)
RETURN
END
COMMIT TRAN TransID
SET @NextID=@NextTKey
GO
如果打開個3個執(zhí)行過程來模擬并發(fā)，那么會有2個窗體出現(xiàn)：
消息 50000，級別 16，狀態(tài) 1，過程 UP_NewTableID，第 28 行
Warning: No such row is updated
由此會看到還是會由于并發(fā)導致有用戶操作失敗，但是較上一個至少將錯誤出現(xiàn)的時間點提前了。
那么有沒有更好的方法，從查詢到更新結束整個事務過程中，不會有任何其他事務插入其中來攪局的辦法呢，答案很明確，有，使用鎖！需要選擇適當?shù)逆i，否則效果將和上面的一樣。
復制代碼 代碼如下:
ALTER PROCEDURE UP_NewTableID
@TCode VARCHAR(20),@NextID INT OUTPUT
AS
DECLARE @CurTKey INT,@NextTKey INT
BEGIN TRAN TransID
SELECT @CurTKey=TKey
FROM KeyTable WITH (UPDLOCK)--采用更新鎖，并保持到事務完成
WHERE TCode=@TCode
IF @@ROWCOUNT=0BEGIN
ROLLBACK TRAN TransID
RAISERROR('Warning: No such row is exists',16,1)
RETURN
END
SET @NextTKey=@CurTKey+1
WAITFOR DELAY '00:00:05'
UPDATE KeyTable
SET TKey=@NextTKey
WHERE TCode=@TCode--此處無需驗證TKey是否與SELECT的相同
COMMIT TRAN TransID
SET @NextID=@NextTKey
GO
可以打開N（N>=2)個窗體來進行測試，將會看到所有操作都被串行化，結果就是我們想要的那樣。如此注釋或者去掉模仿并發(fā)的語句WAITFOR DELAY '00:00:05'即可。
如前面所說，這同樣適應于單據(jù)編號類似編碼的產(chǎn)生形式，只要對前面的代碼及鍵值表稍作修改即可，有興趣的朋友可以一試。如果是從前端取得這個編號，并應用于各個記錄，那么可能存在跳號的可能。如果為了保證不存在跳號，一種解決方案就是使用跳號表，將跳號記錄定期掃描并應用于其他記錄。另一種解決方案是將記錄的保存操作放置到編號產(chǎn)生的過程中，形成一個串行化的事務。
俗話說蘿卜白菜各有所愛，您用哪一種自有你的道理。
相關文章
本文由腳本之家小編給大家分享了五種sqlserver分頁存儲過程及性能比較，接下來我們跟著小編一起了解了解吧2015-09-09
SQL?Server2019安裝后出現(xiàn)連接失敗的解決方法
在開發(fā)中我們經(jīng)常會用到SQL?Server,下面這篇文章主要給大家介紹了關于SQL?Server2019安裝后出現(xiàn)連接失敗的解決方法,文中通過圖文介紹的非常詳細,需要的朋友可以參考下2022-12-12
詳解SqlServer數(shù)據(jù)庫中Substring函數(shù)的用法
substring操作的字符串，開始截取的位置，返回的字符個數(shù)，本文通過簡單實例給大家介紹了SqlServer數(shù)據(jù)庫中Substring函數(shù)的用法，感興趣的朋友一起看看吧2018-04-04
SQL SERVER函數(shù)之深入表值函數(shù)的處理分析
本篇文章是對表值函數(shù)進行了詳細的分析介紹，需要的朋友參考下2013-06-06
SQL 合并多行記錄的方法總匯，方便有此需要的朋友參考。2009-06-06
SQL學習筆記六 union聯(lián)合結果集使用，需要的朋友可以參考下。2011-08-08
SQL Server高可用不就是微軟的那幾個技術嗎，如Replication, Failover Clustering,本文將詳細介紹，有需求的朋友可以參考下2012-11-11
SQL注入（SQL Injection）攻擊是其中最普遍的安全隱患之一，因此，如何防范SQL注入攻擊成為了網(wǎng)絡安全領域的一個重要議題。本文通過代碼示例詳細介紹了SQL注入攻擊，需要的朋友可以參考一下2023-04-04
SQL Server中row_number函數(shù)的常見用法示例詳解
這篇文章主要給大家介紹了關于SQL Server中row_number函數(shù)的常見用法，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2020-09-09
這篇文章主要為大家介紹了SQL?Server的觸發(fā)器，具有一定的參考價值，感興趣的小伙伴們可以參考一下，希望能夠給你帶來幫助2022-01-01