結合數據庫表

我有兩張看起來很相似的表格，我在考慮將它們結合起來，並認爲我會從每個人那裏得到一些輸入。這裏是他們現在的樣子：結合數據庫表

問題

Id | IssueCategory | IssueType | Status | etc.. 
------------------------------------------------- 
123 | Copier   | Broken  | Open | 
124 | Hardware  | Missing | Open |

CopierIssueDetails

Id | IssueId | SerialNumber | Make | Model | TonerNumber | LastCount 
--------------------------------------------------------------------- 
1 | 123  | W12134  | Dell | X1234 | 12344555 | 500120

HardwareIssueDetails

Id | IssueId | EquipmentNumber | Make | Model | Location | Toner | Monitor | Mouse 
----------------------------------------------------------------------------------- 
1 | 124  | X1123113  | Dell | XXXX | 1st floor | 0  | 1  | 0

您如何看待這兩個表合併成一個什麼。這是一個好主意還是讓它們保持這種分離狀態更好？

來源

2010-05-12 zSynopsis

您是否可以獲得CopierIssueDetails記錄*沒有* HardwareTicketDetails記錄的同一個問題ID或者他們是否在該方向配對？（我假設可以擁有HardwareTicketDetails記錄而沒有關聯的CopierIssueDetails記錄） – 2010-05-12 16:02:18

是的。當前系統確定選擇的類別插入哪個表格，並且每個問題只能選擇一個類別。 – zSynopsis 2010-05-12 16:05:12

最終問題歸結爲「這是一對一還是一對多的比例？」如果有可能在給定的表中有兩個或更多項目與另一個表格中的項目有關，請將它們分開。如果沒有，那麼將它們組合起來將簡化您的查詢。

來源

2010-05-12 16:02:12 JYelton

我應該提到，對於適用於某種類型問題但不適用於另一類問題的字段，請確保您的應用程序有一些處理空數據或其他不適用數據的其他佔位符的方法。 – JYelton 2010-05-12 16:03:57

+1正確。這不是唯一的考慮因素，但它是一個關鍵。 – Smandoli 2010-05-12 16:11:26

你當然可以，但你可能想考慮使列更通用一些，這樣你就不會有空列。例如，您知道複印機沒有顯示器或鼠標，因此複印機行有顯示器/鼠標列是沒有意義的。你可以把這些列更通用的，通過將其更改爲所謂的「HardwareType」與值一列：

0 =監控，

1 =鼠標，

2 =監控&鼠標，

3 =複印機

（然後，您可以將它放在查找表中，以跟蹤您的ID）。

要考慮的事情是：

1）雖然結合這些表增加應用的速度？

2）雖然結合這些表增加了應用程序的維護？

如果表格都非常大，並用於不同的任務，它可能不明智。對於概念上「大致相同」的表格，只要不影響性能就可以將它們結合起來並不錯，只要避免了僅針對特定項目的大量不必要的列，但是不是別人。

來源

2010-05-12 16:05:26 AlishahNovin

那麼，這取決於你期望這種複雜性在未來有多大。

如果僅僅只有少數幾個具體領域不同且具有許多共同領域的問題類型，將它們組合成一個並將這些領域置於null並不適用於特定情況是有意義的。

其他方法可能是將所有的公共字段合併爲一個表，並添加另一種常見的其他詳細信息的表狀結構：

IssueID 
FieldName 
FieldValue_Text 
FieldValue_Number 
FieldValue_Float

，並且可以附加字段名稱主表中包含列：

FieldID 
FieldName 
DataType

最後，我會說這是一個上下文，它可以證明任何設計的合理性，並且在不查看完整圖片的情況下很難斷言您的問題。

來源

2010-05-12 16:05:59

我需要一個令人信服的理由來合併它們，因爲它們看起來不一樣。也許有一個令人信服的理由，但我沒有看到一個提供的。

在機械設計中，我們需要決定兩個零件是否足夠相同以便被相同的零件號調用，或者是不同的並且應該具有不同的PN。決定這一點的規則是「Form，Fit，Function」。

形式：它們「是否一樣？」
適合：它們可以互換嗎？
功能：他們是否執行相同的的目的，滿足相同的需求？

您可以嘗試將此條件應用於您的模式。

來源

2010-05-12 16:08:17 Smandoli

補充說明：您可能已經注意到「Form」有點含糊。我猜，這就是一位工程師可以放大他們的風格偏好的地方。 – Smandoli 2010-05-12 16:10:01

要考慮的問題：

執行表具有不同的數據？我竭力避免製作過於通用的字段。在這種情況下，「序列號」和「設備編號」聽起來像他們可能是幾乎相同的東西。但是「Last Count」不適用於電腦，「Monitor」和「Mouse」不適用於我知道的任何複印機。是的，如果不適用，您可以讓這些字段爲空。如果結合使用，我強烈建議您不要創建一個包含計算機「鼠標」代碼和複印機計數的字段。這樣瘋狂的謊言。但是，您可以包含兩組字段，並在不適用時將它們留空。
這些表的使用方式是否有所不同？如果你有一套你只做硬件問題的工作，或者預計只做硬件問題的一套工作，另一套工作只對複印機問題起作用，而對於兩者都起作用的很少或沒有任何工作，這是將它們分開的一個很好的理由。如果有很多操作同時處理這兩個表，並且您不斷在兩個表上編寫UNION，那麼這表示它們應該是一張表。雖然我相信原則上你的模式應該模擬你正在處理的真實世界，並且代碼應該在模式之後，實際上，如果在編寫代碼時你反覆看到不同的模式會更容易處理，這是一個強大的線索，你不能準確地模擬你正在處理的真實世界。
您可能創建什麼未來數據？是否還有其他六種類型的「問題」會與您打交道，因此您將不再使用3個表格，而是9個？如果是這樣，那些數據將攜帶？他們將如何使用？或者這可能嗎？

我會考慮最後的表現。改變你的模式以提高性能應該是隻有在性能被證明是一個問題之後，或者你已經做了一些實際的基準來證明它會是的時候。在數據庫上進行了許多過早的性能優化，實際上在提高性能的過程中很少或根本沒有提高性能，但導致數據不規範和不嚴格。

來源

2010-05-12 16:24:49 Jay

我在這些情況下考慮的一件事是「這些事情將如何演變？」。例如，如果您需要爲複印機添加新列，那麼硬件可能需要同一列的可能性是多少？關於報告，你通常需要結合這些信息，還是通常有兩種類型的報告？

如果這兩件事看起來可能會發展/單獨使用，那麼我會建議忽略它們看起來非常相似的事實;否則，最終會遇到在您的查詢中散佈的特殊情況。

來源

2010-05-12 16:25:10

結合數據庫表

回答

相關問題