MySQL，如何重組可選的多個外鍵

Question

對於此示例，我正在嘗試構建一個系統，該系統將允許來自多個來源的輸出，但是尚未構建這些來源。 輸出“模塊”將是一個組件，每個源將是其自己的組件，以供以后構建和擴展。

這是我在MySQLWorkbench中設計的一個示例：

目標是使我的輸出模塊顯示輸出表中的數據，同時在以后構建更多源時輕松對其進行擴展。 我還想在添加新源時最小化架構更新。 當前，我將必須為每個源添加一個新表，然后將一個外鍵添加到輸出表。

有一個更好的方法嗎？ 我不知道我對這些可為NULL的外鍵的感覺如何，因為JOIN查詢將包含IFNULL並將很快變得不規則。

思考？

編輯1：澄清

我將使用輸出表中的數據顯示網格。 輸出表將包含網格中所有項目的常規數據，並且基本上將充當output_source_X表的聚合器：

output(id, when_added, is_approved, when_approved, sort_order, ...)

output_source_X表將包含特定於源的其他數據。 例如，假設輸出源表之一用於Facebook帖子，因此該表將包含特定於Facebook API的列：

output_source_facebook(id, from, message, place, updated_time, ...)

另一個可能是Twitter，因此這些列專門針對Twitter：

output_source_twitter(id, coordinates, favorited, truncated, text, ...)

第三個輸出源表可以是Instagram，因此output_source_instagram表將包含特定於Instagram的列。

與輸出表和output_source_X表中只有一個一對一的外鍵關系，這取決於輸出項是Facebook，Twitter，Instagram還是其他類，因此，可以為NULL的外鍵鍵。

output table
------------
foreign key (source_id_facebook) references output_source_facebook(id)
foreign key (source_id_twitter) references output_source_twitter(id)
foreign key (source_id_instagram) references output_source_instagram(id)

我想我擔心的是這不是我想要的模塊化，因為我也想添加其他源，而不必太多更新架構。 當前，這要求我使用任何不為null的外鍵在輸出表上加入output_source_X。

Answer 1

這種設計在某些方面幾乎可以肯定是不好的。

目前尚不清楚您的設計代表什么，但是簡單的設計將是這樣的：

// source [id] has ...
source(id,message,...)
// output [id] is approved when [approved]=1 and ...
output(id,approved,...)
// output [output_id] has [source_id] as a source
output_source(output_id,source_id)
foreign key (source_id) references source(id)
foreign key (source_id) references source(id)

也許您有不同的輸出和/或來源子類型？ 基於來源和/或輸出？ 也許每個來源都只能提供特定的輸出？ 是“產出”和“源”實際上是種輸出和來源，這是信息不輸出的方式采購，但對信息什么樣的輸出源配對的是permittted？

請為我們提供您要針對應用程序編寫的基本語句的參數，這些語句由列名參數化。 即針對您感興趣的應用程序關系。（例如，如上面的代碼注釋。）（您可以為圖解設計完成此操作，但可能會過於復雜且不能真正反映您要建模的內容。）

重新編輯：

與輸出表和output_source_X表中只有一個一對一的外鍵關系，這取決於輸出項是Facebook，Twitter，Instagram還是其他類，因此，可以為NULL的外鍵鍵。

您有一個超類型的多個不相交子類型的情況。

您的情況與該問題非常相似，不同之處在於它們具有一個子類型區分符/標簽列，該列指示哪個子類型表，您具有一組列，非空列指示哪個子類型表。 請參閱Erwin Smout和我的答案。 也這個答案 。

請為您提供關於您的應用程序的基本陳述的列名稱參數化的陳述

並且您會發現簡單明了的語句（如上所述）。 如果您給出當前設計的陳述，您會發現它們很復雜。 另請參閱。

我想我擔心的是這不是我想要的模塊化，因為我也想添加其他源，而不必太多更新架構。

與正確的子類型設計相比，您的結構並未減少架構更改。

無論如何，DDL在那里。 您可以僅通過丟失DBMS管理完整性來通用化子類型以避免DDL。 僅基於評估DDL與DML性能的權衡，這才是相關或合理的。 搜索重新（通常是反模式）EAV。

（ 僅當您表明創建和刪除新表是不可行的，並且對應的可怕的完整性和並發性挑戰的巨型聯接表和元數據編碼表中的EAV信息等效設計才是可行的，才應考慮使用EAV 。）