2012-06-06 28 views
2

我需要存儲一些與某些實體相關的審閱標誌。每個審查標誌只能與單個實體屬性組相關聯。例如,表Parents有一個ParentsStatus標誌,而表Children有一組ChildrenStatus標誌。在數據庫中實現審閱標誌;最佳做法

在目前的設計方案,我有三個表:

  • ReviewTypes:商店的標誌和它們與性能。
  • ReviewPositions:存儲標誌可以具有的值。
  • Reviews:存儲交易數據,實際評論。它就像UsersToFlags:Flags in a database rows, best practices

問題是我得到推回來,沒有必要有Reviews表,它最好只存儲在每個實體上的實際審查數據。例如,向Parents添加一個額外的列以保存ParentsStatus。他們認爲這是一個更簡單的解決方案,將數據分離出來只是爲了解決場外情況。

我不喜歡這個想法,因爲這意味着每次我們想添加一個新的審查標誌時,我們需要更新核心實體表來保存該標誌。

空間不是問題。

人們有沒有強烈的意見?

編輯:

此評論適用於三個答案。共識是關係型方法是最好的,但我認爲我需要閱讀更多關於EAV模型,從一些非常基本的閱讀Best beginner resources for understanding the EAV database model?及其相關鏈接,它似乎不是非常直接,我不想挖我自己一個洞。感謝wildplasser。一旦我讀了更多,我會回頭看看。

+1

我不確定我是否理解你的敘述 - 你能否提供一些你希望在每個表格中看到的數據的示例數據(希望在兩個正在考慮的佈局下 - 顯示每種模式的相同數據)。 –

+0

我看不到問題。你所提出的(據我所知)基本上是一個EAV數據節點1,除了來自特殊枚舉類域(ReviewPosistions表)的標誌 – wildplasser

+0

@Damien_The_Unbeliver:如果有幫助,我可以做一些示例數據。帶我幾分鐘。 –

回答

3

哦,是的。他們的想法比較簡單,直到你想加強它。鑑於該計劃,他們正在提議如果兩個評論需要每個實體。如果你想附加諸如筆記/註釋之類的其他東西,該怎麼辦?一旦他們發現他們的想法是多少充氣飛鏢,你有什麼需要轉移到更有用的飛鏢?更不用說,你需要一些方法來識別狀態字段,像Column Name這樣脆弱的垃圾以「_Status」結尾,或者你必須在某個地方對它們進行硬編碼。

這樣做並不是更多的工作,它並不複雜,事實上在許多方面它更簡單,它將以低得多的成本應對可改變的變化。

1

爲什麼我喜歡評論表單獨的一個原因是您可以保留您可能不想顯示的更改(因爲它尚未經過審查和批准),並且仍然保留舊的dat,直到新的批准爲止。我不知道你的情況是否需要。

爲了使未來的編程更簡單,當您想要顯示更改時,可以編寫一個顯示新舊數據的視圖。

2

歸一化總是優於過早優化。

相關問題