2011-05-15 125 views
0

這是我現在在哪裏。我有四個表:任務,項目,機會和task_xref。項目和機會表每個都與任務有一對多的關係。我將這些關係存儲在task_xref中。該模式看起來像這樣對每個表(簡體):如何處理多於2個表的多對多關係?

task 
---- 
id(pk) 
name 

project 
------- 
id(pk) 
name 
... 

opportunity 
----------- 
id(pk) 
name 
... 

task_xref 
--------- 
task_id(task id) 
fkey(other table id) 

假設項目和機會的關鍵將是不一樣的(GUID),這樣的機會不能爲項目取任務等。這表面上工作得很好,一個外部參照表維護任務和項目,機會(或任何其他未來可能需要任務關係的表)之間的關係。

我目前的困境是雙向的。如果我想要獲得單個項目或機會的所有任務,那就沒有問題了。如果我拉回任務並想知道相關項目的名稱或機會,我不能。我無法知道相關的Fkey是一個項目還是一個機會。在未來,我可能會有其他表與任務關係;而我現在有兩張桌子,未來可能會有更多。

以下是可能的解決辦法,我認爲到目前爲止: 1)每對單獨的外部參照表(例如task_project_xref,task_opportunity_xref ...) 缺點:我要運行的每個外部參照表尋找查詢一個任務

2)task_xref第三列關係指向父表 缺點:這似乎是一個雜牌我

3)項目,機會主鍵存儲在一個可識別的方式(例如proj1,proj2,proj3,opp1,opp2,opp3),所以我可以通過查看密鑰來判斷任務涉及哪個表3210缺點:這感覺就像我讓項目和機會中的主鍵不可思議,讓它們具有更多的意義,而不僅僅是作爲單個記錄的標識符(也許我過度思考它)

我的問題然後是這樣的嗎?我忽略了其他解決方案嗎?哪種解決方案比其他解決方案更好/更差?

我試圖儘可能保持連接限制,如果可能和性能。我也不反對在代碼中加入數據,如果這有助於簡化事情。

我正在使用PHP和MySQL(目前MyISAM表,但如果有這樣的理由,將使用INNODB)。

回答

0

我更喜歡爲不同的概念有單獨的xref表。這樣,從概念到任務的關係就更容易維護,並與其他概念與任務的關係相隔離。

我倒是也許青睞,如果任何表在設計中可能有任務,然後我只希望有一個額外的列指示哪些類型的對象的所有相關概念的單一外部參照的父任務。

+0

這似乎是它可能是'正確'的解決方案,至少對於我的特定情況,在考慮了用戶如何與應用程序交互之後。正如jodes指出的那樣,我可能需要2個查詢。這樣我就堅持讓每個概念管理自己的數據的模式。 – Jon 2011-05-16 00:18:18

0

如果task_xref具有單獨的project_id和opportunity_id字段,則您的SQL聯接將更加整齊。這是一個很好的方法,因爲查詢很簡單。此外,通過簡單地查看哪些外鍵不爲空就很容易知道它是什麼類型的任務。這也是有效的。加入任務時,需要兩個查詢,因爲項目和機會無疑會有不同的結構,所以結果不能是union