這是我現在在哪裏。我有四個表:任務,項目,機會和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)。
這似乎是它可能是'正確'的解決方案,至少對於我的特定情況,在考慮了用戶如何與應用程序交互之後。正如jodes指出的那樣,我可能需要2個查詢。這樣我就堅持讓每個概念管理自己的數據的模式。 – Jon 2011-05-16 00:18:18