2012-11-30 47 views
0

我正在設計我的數據庫並試圖找出避免未來條件連接的最佳方法。我已閱讀顯示有條件連接的文章,這絕對是我想盡可能避免的事情。通過模型設計避免條件連接

我有一個CHECK表和CHECK將存儲一些數據(金額,日期等)。我也有3個'其他'表,VENDOR,VENDOR_DEPT,VENDOR_ACCOUNT,其中VENDOR_ACCOUNT有一個fk到VENDOR_DEPT,VENDOR_DEPT有一個fk到VENDOR

我的問題是這樣的:我怎麼設計我的模型,以便檢查可以任意分配給VENDORVENDOR_DEPTVENDOR_ACCOUNT無需vend_id,我CHECKvendacct_idvenddept_id或具有具有列check_id一個VENDOR_CHECK表,vendor_leveljoin_id ....(希望你得到的圖片)

有沒有更清潔的方式?順便說一句,我使用MYSQL,但我希望解決方案也可以在其他平臺上工作。

由於我在模型設計階段,我向所有人開放的建議,包括重新設計當然這些表:)

+0

爲什麼檢查總是與供應商帳戶相關聯,您可以從中導出部門和供應商? –

+0

,因爲我希望用戶能夠將支票添加到整個供應商,而不是特定的部門(如果需要的話)。一些供應商可能很小,或者部門可能不存在...想象一下不同的表名:項目 - 分配 - 任務(並且想象它們處於層次結構中:Proj有0個或更多分配並且分配有0個或更多任務)if我有一個'成本'的項目,我想要歸功於該項目,我希望它看起來不同於任務級別的成本。 – NEW2WEB

回答

1

您正在嘗試實行「一中」,在SQL的關係。這種關係可能有點困難。我認爲解決這個問題的「關係型」方法就是說你確實有一個CHECK_ENTITY,這個實體可以是三種類型之一。然而,這看起來不必要的麻煩。

一個建議是在表中有三個不同的列。我的猜測是,您經常想要使用vend_id來進行報告。只需填寫給定CHECK的適當部分即可。

是的,您的數據然後非規範化,因爲vend_id將在CHECK表和VEND_ACCT表中。如果賬戶和部門發生變化,那麼這會捕獲CHECK時的關係,這可能是您想要的。

另一種選擇是擁有一個虛擬賬戶,意思是「整個供應商」。那麼只需使用這個值來表示整個供應商。同樣,您需要每個部門的帳戶。

這種方法需要一些訓練。很容易設置一個供應商層次結構,以任何可能的深度,通過一個鏈接返回父級(帳戶 - >部門 - >供應商,爲什麼不推廣它?)。 SQL在分層查詢中比在一對一關係中更糟糕。通過「更糟」,我的意思是處理這些查詢的方法非常依賴於數據庫。

+0

戈登,夢幻般的迴應。謝謝!我喜歡虛擬帳戶的想法,當然這仍然意味着我需要對數據庫進行多次調用,否則我將不得不利用外部連接來獲取數據。 – NEW2WEB