在MySQL中正確實現超類型子類型

Question

下面是一個數據庫圖，我正在其中試圖確定適當的設計。以下是一些注意事項。

• 員工/經理與客戶有關。
• partyid是一種全球代表一個人的方式;客戶，員工，經理。它是否需要一直傳播下去？它應該是所有表格中的主鍵還是表示個人的表格？
• 做其他的表，如計費，報告，憑證等表需要有自己各自的id是主鍵，例如billingid,reportingid,credentialid等？

關於實體交互的一些註釋。

• 員工有管理器（S）與它們相關聯。
• 客戶有管理器（S）和可能員工與它們相關聯。
• 客戶和員工需要上報時間開單。

Answer 1

表 「當事人」 不看的權利。與來自this other SO question的源代碼進行比較。

在這種結構中，派對號碼向下傳播，可以這麼說。它通常應該是存儲關於某人的數據的表中的主鍵或外鍵。

在您的表格「reporting」中，它看起來像主鍵不應該是'partyid'。這將允許每個員工只有一行，我認爲你不打算。 （我可能是錯的。）如果我說得對，那麼您可能會考慮在{partyid，date}上約束NOT NULL UNIQUE，並在新列'reportid'上約束PRIMARY KEY。 「旅行」和「表演」這些表格可能會引用「reportid」。 （但請繼續閱讀。）

您的圖表中有些地方的實體會獲得額外的密鑰：例如，您的公司爲其員工分配了唯一的員工ID號。沒有理論上的理由，你從這一點上不能使用'僱傭'而不是'派對'來引用僱員。但有是一個實際的原因，你可能不想這樣做。它增加了連接的數量。例如，如果表格「證書」，「工具」，「證書」，「學術」和「合規性」引用employee.employid而不是employee.partyid，則不能只加入「合規性」和「派對」來獲取這個人的名字。你也必須加入「員工」。

其他表格如賬單，報告，憑證等表 是否需要具有它們各自的主鍵的ID，例如， billingid，reportingid，credentialid等？

他們需要一個主鍵;主鍵不一定是一個id號碼。如果有一個現有的自然鍵，則必須確定它並將其聲明爲UNIQUE。

表「orders」應該只有「orderid」作爲其主鍵;使用外鍵參考來識別客戶。在某些情況下，重命名列是有意義的。就客戶而言，將其關鍵'customerid'而不是'parytid'稱作是有意義的。我自己創建一個域名。

create domain PARTY_ID as integer not null; 

然後，在需要派對ID號碼的地方，我會使用域名。

create table customers (
    customerid PARTY_ID primary key references parties (partyid), 
... 

我更願意看管理員的表格。參考它可以保證manager.managerid將解決實際經理，而不僅僅是任何員工。