作爲主鍵是否是一個壞主意？

Question

只考慮數據庫設計問題。假設我有這樣一個表：

CREATE TABLE LEGACYD.CV_PLSQL_COUNT 
(
    RUN_DTTM DATE NOT NULL, 
    TABLE_NAME VARCHAR (80) NOT NULL, 
    COUNT Number(50) PRIMARY KEY 
); 

這是一個壞主意 - 使COUNT成爲PRIMARY KEY嗎？一般來說，我應該如何做出什麼是原始鑰匙的決定？

Answer 1

這是一個壞主意 - 讓COUNT成爲PRIMARY KEY嗎？一般來說，我應該如何做出什麼是原始鑰匙的決定？

候選鍵基於功能依賴性。主鍵是候選鍵之一。沒有正式的方法來查看一組候選鍵並說，「這一個必須是主鍵」。這個決定是基於實際問題而不是形式邏輯。

您的表格結構告訴我們這些事情。

• COUNT是唯一的。無論此表有多少行，您都不會找到兩行具有相同COUNT值的行。
• COUNT決定TABLE_NAME。也就是說，給COUNT一個值，我們將永遠爲TABLE_NAME找到一個且只有一個值。
• TABLE_NAME不是唯一的。我們希望找到幾個具有相同TABLE_NAME值的行。
• COUNT確定RUN_DTTM。也就是說，給定一個COUNT的值，我們將永遠爲RUN_DTTM找到唯一的一個值。
• RUN_DTTM不是唯一的。我們希望找到RUN_DTTM具有相同值的多個行。
• TABLE_NAME和RUN_DTTM的組合不是唯一的。我們希望在單行中找到幾行具有相同TABLE_NAME和RUN_DTTM值的行。
• 沒有其他決定因素。這意味着給定TABLE_NAME的值，我們會爲COUNT和RUN_DTTM找到多個不相關的值。同樣，如果我們爲RUN_DTTM賦值，或者賦給一對列{TABLE_NAME，RUN_DTTM}的值。

如果所有這些事情都是真的，那麼COUNT可能是一個很好的主鍵。但我懷疑所有這些事情都是真的。

僅基於列名 - 有風險的方式繼續 - 我認爲唯一候選鍵是{TABLE_NAME，RUN_DTTM}的可能性更大。我認爲也可能是RUN_DTTM被錯誤命名，或者RUN_DTTM的數據類型錯誤。如果這是一個日期，你可能打算命名爲RUN_DT;如果是時間戳，數據類型應該是TIMESTAMP。