候選鍵的概念只存在於理論上嗎？

我知道RDBMS理論中候選鍵的概念，但是候選鍵真的存在於實際的SQL引擎中嗎？我的意思是有沒有辦法在任何 SQL 數據庫管理系統（比如 SQL Server、Postgres、MySQL、Oracle 等）中指定一個特定列或一組列作為候選鍵？

是否有任何保留關鍵字用於將列指定為候選鍵，例如PRIMARY KEY主UNIQUE鍵列和唯一列？

我覺得UNIQUE約束本身提供了候選鍵概念的實現。CANDIDATE KEY我認為擁有單獨的關鍵字沒有任何實際價值。是這樣嗎？

據我所知，沒有 SQL 數據庫管理系統（DBMS）提供CANDIDATE KEY這樣的關鍵字，但是（我認為你在問題中建議）這並不意味著候選鍵的概念（或功能）不能在 SQL 表中配置。

如何表示候選鍵

例如，如果

• 沒有為正在考慮的表聲明主節點，並且
• 配置有 UNIQUE 約束的一整套列（即一個或多個）也用相應的 NOT NULL 約束固定，

那麼設計器就是代表一個候選鍵。

例如，下表顯示了三個不同的候選鍵：

CREATE TABLE Foo (
   FooId  INT      NOT NULL,
   Bar    CHAR(30) NOT NULL,
   Baz    DATETIME NOT NULL,
   Qux    INT      NOT NULL,
   Corge  CHAR(25) NOT NULL,
   Grault INT      NOT NULL,
   Garply BIT      NOT NULL,
   Plugh  TEXT     NOT NULL,
   CONSTRAINT Foo_CK1 UNIQUE (FooId),          -- Single-column CANDIDATE KEY
   CONSTRAINT Foo_CK2 UNIQUE (Bar),            -- Single-column CANDIDATE KEY
   CONSTRAINT Foo_CK3 UNIQUE (Baz, Qux, Corge) -- Multi-column  CANDIDATE KEY
);

如您所知，以這種方式設置的候選鍵容易成為一個或多個外鍵約束的引用。

值得強調的事實是，由於 SQL 及其方言包含 NULL 標記的概念，因此單獨的 UNIQUE 約束不足以代表候選鍵（如上面的 DDL 範例中所述）。這一點特別重要，因為作為候選鍵約束的列不能保留 NULL 標記，否則它不能被視為真正的候選鍵（此外，有理由認為在其任何列中包含 NULL 標記的表不能被視為關係表，但是，是的，這是一個不同的主題）。

這與CANDIDATE KEY關鍵字方法有何不同？

這樣，如果某個 SQL DBMS 的供應商/開發者想要提供CANDIDATE KEY關鍵字，那麼這種約束除了明顯的唯一性強制之外，還必須確保拒絕任何在相關列中插入 NULL 標記的嘗試。 )，使其與結合 UNIQUE和NOT NULL 約束的方法不同的因素。

如何描繪備用鍵

如果相反，

• 選擇了一組列並將其定義為給定表的主鍵，並且
• 其他列集被約束為 UNIQUE，並且該集的每個成員也被固定為 NOT NULL 約束，

然後設計者代表一個備用鍵（如果某個表有一個或多個候選鍵，其中一個被授予主鍵狀態，那麼其餘的成為備用鍵）。

例如，下表顯示了一個主鍵和三個備用鍵：

CREATE TABLE Foo (
   FooId  INT,
   Bar    CHAR(30) NOT NULL,
   Baz    DATETIME NOT NULL,
   Qux    INT      NOT NULL,
   Corge  CHAR(25) NOT NULL,
   Grault INT      NOT NULL,
   Garply BIT      NOT NULL,
   Plugh  TEXT     NOT NULL,
   CONSTRAINT Foo_PK  PRIMARY KEY (FooId),           -- Single-column PRIMARY KEY
   CONSTRAINT Foo_AK1 UNIQUE      (Bar),             -- Single-column ALTERNATE KEY
   CONSTRAINT Foo_AK2 UNIQUE      (Baz, Qux, Corge), -- Multi-column  ALTERNATE KEY
   CONSTRAINT Foo_AK3 UNIQUE      (Grault)           -- Single-column ALTERNATE KEY
);

顯然，如上所示的備用鍵可以從一個或多個外鍵約束中引用。

CANDIDATE KEY在已有 PRIMARY KEY 時使用關鍵字？

假設有一個確實提供CANDIDATE KEY關鍵字的 DBMS，如果表聲明了主鍵，則應拒絕創建候選鍵，並且所述 DBMS 還應在適用ALTERNATE KEY時提供表示一個或多個備用鍵的關鍵字.

(i) 具有一個候選鍵和 (ii) 具有主鍵的同一張表的圖示

是的，在數據庫的邏輯抽象級別，候選鍵是通過表級 UNIQUE 約束結合適用的列級 NOT NULL 對應項建立的，範例如下：

CREATE TABLE Foo (
   FooId  INT      NOT NULL, 
   Bar    CHAR(30) NOT NULL,
   Baz    DATETIME NOT NULL,
   CONSTRAINT Foo_CK UNIQUE (FooId)
);

…相當於設置如下所示的主鍵：

CREATE TABLE Foo (
   FooId  INT,
   Bar    CHAR(30) NOT NULL,
   Baz    DATETIME NOT NULL,
   CONSTRAINT Foo_PK PRIMARY KEY (FooId) -- Single-column PRIMARY KEY, constraint that implies the rejection of NULL marks.
);

這是因為，如果給定的表只有一個候選鍵（如前所述，它可以是複合的，即由兩列或多列組成），那麼它可以自動被認為是主鍵。

物理層面的支持

而且，是的，為了支持 UNIQUE 約束，一些 DBMS可能會使用一個索引，其類型與用於維持 PRIMARY KEY 對應項的索引不同（例如，非聚集與聚集），但這是一個因素這是物理（或內部）抽象級別的一部分（順便說一下，根據使用的 DBMS，它可能適用也可能不適用），因此它完全超出了為表配置的邏輯級別約束的範圍（只要 DBMS 保證列中包含的值的唯一性

$$ s $$涉及）。

我會冒昧地猜測你已經完成了基於 Elmasri 和 Navathe 教科書的課程。這本書理論性很強，不是最清晰的散文，而且它傾向於使用在其他地方沒有廣泛使用的術語。最終結果是，它似乎在半定期的基礎上使學生感到困惑——許多（如果不是大多數）這樣的問題似乎源於試圖理解這本教科書的學生。

在數據建模中，候選鍵是可用於標識記錄的可能鍵。可能只有一個或多個；有些可能是單個引用，有些可能是屬性的組合。它純粹是一個建模概念，用於描述您可以選擇用作主要標識符的鍵。

RDBMS 中的表只能有一個主鍵（在設計時選擇），但它們可以有多個唯一性約束。通常您會選擇一個密鑰（或添加一個合成密鑰）並將其用作主要標識符。您還可以在構成其他候選鍵的列上創建唯一性約束，儘管以這種方式物理化時這些不稱為候選鍵。

引用自：https://dba.stackexchange.com/questions/228423