一對一ER與類型或狀態表而不是類型或狀態列

我有很長的路要走與ER建模，你很快就會看到，但我有一個項目，我正在做的建設堅定不移，我正在掌握數據庫模型。一對一ER與類型或狀態表而不是類型或狀態列

該公司是一家屋頂檢測公司，他們在網站上提供項目和潛在項目建議。

項目可以是諮詢，檢查或報告（類型）。
該項目要麼完成，要麼正在進行中，要麼處於某個階段，他們要求RFF（準備好最終）（州）。

提案可以具有與項目相同的TYPE，但具有其自己的STATUS狀態。

一個項目也包含許多具有自己的一套STATUS的旅程。

所以我目前的模式看起來像這樣：

Simplified Er Model

這是一個好辦法？或者是最好有一個單獨的表爲每個實體，如：Project_Status和Project_Type等....？

甚至只是項目中的一列作爲字符串，並將應用程序中的輸入限制爲三種類型之一？

來源

2015-05-13 Chris Shields

我喜歡分離的實體方法，我在工作中使用它。這樣我可以更靈活地處理TYPE和STATUS的值。從一個軟件開發點我寧願使用它們：

當我將需要在今後的發展，比如使用這個值：表格組件，如組合框和下拉菜單列表依靠ID和值。
當應該將更多的值添加到類型和狀態時，我將使用簡單的插入查詢將它們添加到表中，而不是更改代碼。

來源

2015-05-13 09:03:10

好的，即使有幾個實體現在會有重複的數據？例如Project_Type和Profile_Type將基本相同？它是有道理的，我猜想與Project_Status和Profile_Status，因爲他們會看起來不同有不同的狀態，但只有一點點。我覺得這是一個棘手的概念得到正確的結果 –

當你填寫或更新項目時，想想你的系統中的表單。您可能會有一個下拉列表來選擇提案的類型和項目的類型。此下拉列表正在使用存儲庫的類型表。如果您有一個類型表提供提案和項目，則用戶可以在所有類型中進行選擇，並且他可以選擇不適合項目或提案的類型。如果你真的想讓一個表添加一個字段來輸入包含項目或提議等值的表格，但從長遠來看這不是一個好主意。使用2表甚至認爲它們幾乎完全相同 –

一對一ER與類型或狀態表而不是類型或狀態列

回答

相關問題