SQL Server：IDENTITY約束的缺點

我想談談SQL Server中約束IDENTITY的缺點。在我看來，這是有幫助的，但可能會導致與外鍵異常。SQL Server：IDENTITY約束的缺點

例子：

create table letters 
(
    ID int identity, 
    letter varchar(1) 
)

現在我將創建兩個字母：

insert into letters (letter) values ('a'); 
insert into letters (letter) values ('b');

，並創建每個字母引用的表：

create table references 
(
    ID int identity, 
    ID_letter int references letters(ID), 
    value int 
)

我希望有參考'b'字母，以便我：

insert into references (ID_letter,value) values (2,100)

但現在如果我刪除「A」和字母在另一個數據庫中執行「B」的插入，我必須更改參考1而不是2，因爲「B」現在ID爲1

這就是爲什麼我寧願使用名稱作爲主鍵和引用名稱，而不是ID標識。但是，對於較長的變種，例如城市來說，這並不容易 - 編寫城市的ID而不是全名更容易。你有什麼意見？

來源

2014-10-06 jakub

我不確定我是否理解這個問題，您是否試圖讓外鍵引用一個完全不同的數據庫？ – 2014-10-06 11:16:09

「身份」本身並不是一個問題，它是自然與代理主鍵的永恆聖戰。兩種方法都有強弱兩面，所以一切都取決於你的特定情況。 – 2014-10-06 11:23:46

@jakub，我認爲你的問題真的是關於替代關鍵利弊。這個問題太廣泛了。見http://en.wikipedia.org/wiki/Surrogate_key – 2014-10-06 11:43:43

我的意見是你誤解了什麼是身份。這也是一個廣泛的話題。

身份只是特定行的（唯一）編號。除非你這樣做，否則它不會自動成爲關鍵，主要或其他。
它也沒有數據庫範圍，它絕對不是全球唯一的。除非你做錯了，否則它不會以這種方式使用。

身份通常用作主鍵，以避免必須製作多個行的組合鍵，因爲這樣可以更輕鬆地查找並減少索引的大小。即使它是一個鍵，它也不一定是表的聚集索引，但可以只是一個非聚集索引。這是一個相關的，但仍然可以替代的路線，所以我不會朝這個方向太深。

所以一個身份永遠不會導致異常與外鍵。你對身份的使用可能會導致問題，但這是你想要做的事情，比工具本身更重要。

如果您希望數據密鑰在多個數據庫中保持一致，您可以使用各種「系統密鑰」。通常建立在數據本身或從數據計算。爲此，您通常會使用uniqueidentifiers（guid），應用程序中生成的序列號或字母表中的字母，它自身的字母是有效的比較鍵。

當談到城市時，如果您確信會處理拼寫，那麼您可以使用該名稱，否則，您將包含另一個標識符，這取決於您想要一起聊天的兩個系統之間的邏輯關係，以及你如何交換數據。另外當談到跨數據庫時，主鍵不會自動地意味着相同，並且兩者之間的引用更不如此;即使數據很容易關聯。因爲它很大程度上取決於如何使用數據（這又將我們帶回索引的構建）。

身份只是數據庫工具箱中的一個工具。你如何使用它取決於你，但作爲任何工具，它更適合於某些任務，不適合每一項任務。

來源

2014-10-06 11:24:01

SQL Server：IDENTITY約束的缺點

回答

相關問題