2017-05-04 100 views
0

我試圖爲SQL/Java應用程序建模一組實體。對具有共同和特定屬性的實體樹建模

我將不得不處理不同的實體,如汽車,卡車,無人駕駛飛機和船隻。

所有這些實體實際上是一個設備。一臺設備可以依靠另一臺設備,比如一輛卡車的拖車。

我只能擁有一個設備實體,在設備依賴於另一個設備的情況下引用自身。但是,如果這些設備具有共同屬性,如parent_id,serial_number,它們也將具有非常不同的屬性,並且在一個實體中具有如此多不同的屬性會使其膨脹。

我希望有具體的實體的各種設備,一個是船,一個用於卡車,等...

我不知道如何在SQL表方面對此建模。

任何提示?

+0

這取決於許多變量。例如,您多長時間一次向系統引入新型設備? –

+0

@ZoharPeled假設我從3種類型的設備開始,每種都有15到20個特定屬性 – Stephane

回答

0

這開始了作爲一個評論,但它的轉向了是太長了,所以這裏有雲:

首先,爲了正確地回答這個問題,必須有儘可能多的數據可能 - 一個完整的規範當然,需要存儲的數據是最好的。甚至最糟糕的是,請幾位專家級數據庫管理員,向他們提供完全相同的數據,並且您可能會發現自己有兩種截然不同的方法。話雖如此,我會盡力回答你的問題。

EAV反模式的靈活性與爲每種設備類型設置表格的安全性之間存在權衡。還有其他一些方法來設計數據庫,例如「繼承」 - 您有一個設備基表,其中包含所有屬性,以及每種特定類型設備的不同表格,鏈接爲1:1關係用基礎設備表來保存所有獨特的屬性。
這就是我在評論中詢問的原因通常是你給系統引入了一種新的設備 - 因爲如果它是在高頻率下完成的,你可能需要考慮像EAV這樣的東西,但如果它是低的頻率,那麼我會建議爲每個設備使用不同的表格。

關於使用基礎設備表的問題 - 它取決於其他因素,例如 - 是否有需要在外鍵鏈接到所有設備類型的屬性?在這個問題的背景下,我能想到的一個例子是manufacturer,或者甚至是colors - 這些都是您寫的所有設備類型都應該共用的屬性,但也需要採用1:M的關係 - 每輛卡車都是由由同一製造商生產,但同一製造商也可能生產汽車或船隻,而且所有產品至少有一種基本顏色。

+0

我將避免使用EAV模式。至於有一個基礎設備表,你說它取決於一些因素,顯示其中之一。僅考慮這一因素,是否需要通用外鍵屬性提倡使用或避免基表? – Stephane

+1

不足以決定。如果他們都在多方面,那麼是的。如果他們都在一邊,比不。 –

相關問題