使用增量為 -1 的 IDENTITY 列
我需要執行一個 sql server logging db，其中 2 個主表在 2 個單獨的數據中心同時寫入這兩個數據中心。
我的想法是將數據庫恢復到新的數據中心，然後將標識列重新設置為 -1 並將增量設置為 -1，這樣當需要組合數據時，就不會有任何重複 id 的機會。DATACENTRE1 是正整數，DATACENTRE2 是負整數
-1 的增量會導致任何問題嗎？
倒退對我來說是錯誤的。
只有兩個數據中心，您還可以實施身份範圍。除非您以驚人的速度循環瀏覽身份值，否則您沒有理由不能擁有：
-- Data center 1 CREATE TABLE dbo.Table ( ID INT IDENTITY(1,1) PRIMARY KEY -- , ... ); -- Data center 2 CREATE TABLE dbo.Table ( ID INT IDENTITY(1000000000,1) PRIMARY KEY -- , ... );這將允許在與數據中心 2 發生衝突之前在數據中心 1 中生成 10 億個（嗯，999,999,999）個值。您可以在數據中心 1 中添加一個 CHECK 約束以防止重疊值，具體取決於您的優先級錯誤與重複。如果您擔心在應用程序的生命週期中任何一個數據中心確實會產生超過十億個值（沒關係你的）。
如果約 10 億還不夠，還有另外兩種選擇可以提供更多喘息空間：
-- Data center 1 ID INT IDENTITY(-2147483648,1) -- Data center 2 ID INT IDENTITY(1,1)這將為每個數據中心提供超過 20 億個非重疊值，在數據中心 1 接近 0 之前沒有碰撞危險。如果這還不夠：
-- Data center 1 ID BIGINT IDENTITY(-9223372036854775808,1) -- Data center 2 ID BIGINT IDENTITY(1,1)或者，如果您想保持所有值 > 0，您可以將正數範圍大致分成兩半（如果您比我更迂腐，您可以比這更精確一些）。
-- Data center 1 ID BIGINT IDENTITY(1,1) -- Data center 2 ID BIGINT IDENTITY(4611600000000000000,1)我什至不知道怎麼說這個數字，但它是巨大的。實際上，當您的曾曾曾曾孫從大學畢業時，您必須在一台速度非常快的電腦上非常努力地使用所有這些值。如果您使用的是企業版，則可以使用數據壓縮，這樣您就不必為所有 8 個字節付出代價，至少在數據中心 1 中，直到那裡的數據量超過 20 億。
在我管理的一個系統中，我採用了稍微不同的方式——我們有多個帶有 Express 實例的 Web 伺服器，它們負責生成需要在企業中唯一的 ID 號。所以我們只是在每台機器上設置了一個序列生成器（它們不需要實際儲存值），使用 BIGINT IDENTITY 列。我們有 < 9 台伺服器，所以它們都是這樣播種的：
-- WEBAPP0001 ID BIGINT IDENTITY(10000000000,1) -- WEBAPP0002 ID BIGINT IDENTITY(20000000000,1) -- WEBAPP0003 ID BIGINT IDENTITY(30000000000,1) ...當使用這些值然後在中央系統中合併時，我們不僅可以保證沒有任何重複，而且還可以很容易地立即辨識它們來自哪個 Web 伺服器（這有時在調試中很有用），而無需引入任何復合關鍵要求。我們也不擔心任何一台 Web 伺服器會產生超過 100 億的價值。
在這種情況下，很多人會使用 GUID，但我認為有幾個強烈的論據反對這種方法。