即使不一定需要，我是否應該在表中使用唯一約束？

Question

在 Microsoft SQL Server 中，創建表時，即使您真的不需要它是唯一的，在列上使用唯一約束是否有任何缺點？

一個例子是對用戶管理系統中角色的描述：

CREATE TABLE Role
(
    ID TINYINT PRIMARY KEY NOT NULL IDENTITY(0, 1),
    Title CHARACTER VARYING(32) NOT NULL UNIQUE,
    Description CHARACTER VARYING(MAX) NOT NULL UNIQUE
)

我擔心在其他表中頻繁插入時驗證此約束將是一個非常耗時的過程。 我不確定如何驗證此約束，但我覺得它可以以非常有效的方式或作為線性比較來完成。

Answer 1

你的擔心變成了現實：UNIQUE 約束是作為索引實現的，這非常耗時和空間。

因此，無論何時插入新行，數據庫都必須更新表，並為每個唯一約束更新一個索引。

所以，根據你：

在列上使用唯一約束，即使您真的不需要它是唯一的

答案是否定的，不要使用它。 有時間和空間的缺點。

您的示例表需要一個用於 Id 的聚集索引和 2 個額外的索引，每個索引對應一個唯一約束。 這會占用空間和時間來更新插入的 3 個索引。

僅當您通過這些字段進行查詢過濾時，這才是合理的。

順便說一句：原始的帖子樣本表有幾個缺陷：

• 該語法不是 SQL 服務器語法（您將其標記為 SQL 服務器）

• 您不能在 varchar(max) 列中創建索引

如果您更正語法並創建此表：

CREATE TABLE Role
(
  ID tinyint PRIMARY KEY NOT NULL IDENTITY(0, 1),
  Title varchar(32) NOT NULL UNIQUE,
  Description varchar(32) NOT NULL UNIQUE
)

然后您可以執行sp_help Role ，您將找到 3 個索引。

Answer 2

數據庫創建一個索引來備份 UNIQUE 約束，因此進行唯一性檢查的成本應該非常低。

http://msdn.microsoft.com/en-us/library/ms177420.aspx

數據庫引擎自動創建 UNIQUE 索引以強制執行 UNIQUE 約束的唯一性要求。 因此，如果嘗試插入重復行，數據庫引擎將返回一條錯誤消息，指出違反了 UNIQUE 約束，並且不會將該行添加到表中。 除非明確指定聚簇索引，否則默認情況下會創建唯一的非聚簇索引以強制執行 UNIQUE 約束。

Answer 3

如果您知道數據將始終是唯一的，但它不一定需要唯一才能正確地應用到 function，那么限制它通常是一個好習慣嗎？

我想問你：兩個角色有不同的頭銜但有相同的描述有意義嗎？ 例如

INSERT INTO Role ( Title , Description )
   VALUES ( 'CEO' , 'Senior manager' ), 
          ( 'CTO' , 'Senior manager' );

對我來說，這似乎貶低了描述的使用； 如果有很多重復，那么做這樣的事情可能更有意義：

INSERT INTO Role ( Title )
   VALUES ( 'CEO' ), 
          ( 'CTO' );

INSERT INTO SeniorManagers ( Title )
   VALUES ( 'CEO' ), 
          ( 'CTO' );

但是話又說回來，您不希望出現重復。

我假設這是一個低活動表。 您說您害怕在其他表中頻繁插入時驗證此約束。 好吧，這不會發生（除非有一個我們看不到的觸發器可能會在更新另一個表時更新此表）。

就個人而言，我會要求設計師（業務分析師，等等）證明不應用唯一約束是合理的。 如果他們做不到，那么我將根據常識強加唯一的約束。 對於這樣的文本列，我通常也會應用CHECK約束，例如禁止前導/尾隨/雙空格、零長度字符串等。

Answer 4

在 SQL 服務器上，數據類型 tinyint 僅提供 256 個不同的值。 無論您在 id 列之外做什么，最終都不會得到一個非常大的表。 即使有十幾個索引列，它也肯定會快速執行。

不過，除了代理鍵之外，您通常至少需要一個唯一約束。 如果您沒有，您很可能會得到這樣的數據。

1    First title    First description
2    First title    First description
3    First title    First description
...
17   Third title    Third description
18   First title    First description

允許此類數據的表格通常是錯誤的。 任何使用外鍵引用此表的表都無法正確報告，例如，使用的“第一個標題”的數量。

我認為在用戶管理系統中允許角色使用多個相同的頭銜是一個設計錯誤。 我可能會爭辯說“標題”對於那個專欄來說也是一個非常糟糕的名字。