這些數據庫設計樣式（或反模式）是否有名稱？

Question

考慮一個包含表格Products和Employees的數據庫。對現有產品經理進行建模有一項新要求，即對產品負責的唯一員工，並指出某些產品簡單或足夠成熟，不需要產品經理。也就是說，每個產品可以有零個或一個產品經理。

方法1：ALTER TABLE Product以使沒有產品經理一個產品是由NULL值模型添加新NULL能列product_manager_employee_ID。

方法2：創建一個新表ProductManagers與非NULL能夠列product_ID和employee_ID，具有唯一性約束product_ID，所以沒有產品經理一個產品是由該表中沒有行的建模。

還有其他的方法，但這些是我似乎最經常遇到的兩個。

假設這些都是合法的設計選擇（我傾向於相信）並且僅僅代表不同的風格，他們是否有名字？我更喜歡方法2，並且發現很難將風格上的差異傳達給喜歡方法1而不採用實際例子的人（正如我在這裏所做的那樣）。如果我可以說，我會更好，「我更喜歡傾向於6NF（或其他）風格我自己。「

假設其中一種方法實際上是一種反模式（因爲我只是通過將兩個實體之間的關係建模爲這些實體之一的屬性來將方法1視爲情況），此反模式是否具有反模式一個名字？

Answer 1

那麼第一個只不過是一對多的關係（一個僱員對許多產品）。這有時被稱爲O：M關係（零對多），因爲它是可選的（並非每個產品都有產品經理）。也不是每個員工都是產品經理，所以在另一方面也是可選的。

第二個是連接表，通常用於多對多關係。但是由於一方只是一對一（每個產品只在表格中一次），這實際上只是一個令人費解的一對多關係。

我個人更喜歡第一個，但都沒有錯（或不好）。

第二個會出現在我們腦海中的兩個原因。

1. 您預想產品有多個管理者的可能性;或
2. 您想跟蹤產品經理對於產品的歷史記錄。你可以這樣做，比如說一個current_flag列設置爲'Y'（或類似的），一次只能有一個是當前的。這實際上是以數據庫爲中心的應用程序中非常普遍的模式。

Answer 2

它在我看來像兩個模型的不同行爲。在第一個示例中，每個產品可以有一個產品經理，一個員工可以成爲多個產品（一對多）的產品經理。第二個似乎允許每個產品有多個產品經理（多對多）。這表明這兩種解決方案在不同情況下同等有效，您使用哪一種解決方案取決於業務規則。

Answer 3

第一種方法存在缺陷。想象一下，業務需求已經發生變化，現在您需要能夠將2產品經理設置爲產品。你會怎麼做？將另一列添加到表格Product？呸。這顯然違反了1NF。

第二種方法提供的另一種選擇是爲某個產品經理< - >產品關係存儲某些屬性。就像，如果你有兩個產品經理的產品，那麼你可以將其中之一設置爲主要... 或者，例如，一名員工可以有一個電話號碼，但作爲產品經理他/她可以有另一個電話號碼...然後這也去特別表。

Answer 4

方法1）

1. 減慢使用產品表的內容與附加產品經理現場（也許不是所有的數據庫，但對於一些）。
2. 從產品錶鏈接到員工表很簡單。

方法2）使用產品表

1. 現有的查詢不受影響。
2. 增加數據庫的大小。您現在已將產品ID列複製到另一個表中，並將唯一約束和索引添加到該表中。
3. 從產品錶鏈接到員工表更麻煩，成本更高，因爲您必須首先將其打印到中間表。

你在兩張桌子之間連接多久？

有多少其他查詢使用產品表？

產品表中有多少條記錄？

Answer 5

在你給出的具體情況下，我認爲兩個表的主要動機是避免缺失數據的空值，這就是我如何表徵這兩種方法的特點。

有討論的優缺點on wikipedia。

我很確定，鑑於c日期不喜歡這個，他定義了關係理論，以便只有多表解決方案是「有效的」。例如，您可以將單表格方式稱爲「輸入較差」（因爲null的類型爲unclear - 請參閱第4頁上的報價）。