用於評估的SQL Server數據庫設計

我正在設計此員工評估網頁，並且想知道我的當前數據庫設計是否正確或者是否可以改進。用於評估的SQL Server數據庫設計

這是我當前的設計

表議程：

+--------------+----------+----------+-----------+------+-------+-------+ | idEvaluation | Location | Employee | #Employee | Date | Date1 | Date2 | +--------------+----------+----------+-----------+------+-------+-------+

Date要執行預定的評估日期。

日期1和日期2其一段時間從其他數據庫檢索一些度量標準。

表評價：

+--------------+---------+------------+------+----------+ | idEvaluation | Manager | Department | Date | Comments | +--------------+---------+------------+------+----------+

表比分：

+--------------+----------+-------+ | idEvaluation | idFactor | Score | +--------------+----------+-------+

idFactor涉及含有該因子和它的描述，就像我說其這個正確的另一個表設計？？

我關心它的這個，目前有60名員工，11個經理和12個因素，每個員工其由每個經理每年兩次評估，所以在Agenda Table有沒有因爲每個評價它的唯一一個記錄的麻煩（60員工= 60條記錄），Evaluations Table有多少次每個評估有11條記錄，因此它會記錄到660條記錄（60名員工* 11名經理= 660名），然後在Scores Table上更大，因爲有每次評估需要12個因子，共計7920條記錄（660個評估*每個因子12個= 7920）。

這是正常的嗎？我做錯了嗎？任何輸入其讚賞。

編輯

地點，員工，#Employee，經理和部會自動由vb.net頁面，它們都是「進口」從Active Directory和檢查之前插入所以重名，名字拼錯裝，這種事情不是問題。

來源

2016-10-20 abichango

考慮到正確的管理，7,920條記錄只是SQL服務器可以處理的水載量的下降。您應該進一步考慮這些問題，併爲員工，部門，地點和經理分別設置不同的表格，以免重複這些名稱。基本上，這些表格中的大部分都會有一堆ID。 –

@Cᴏʀʏ我曾考慮過員工，地點和離職表，但是關於經理，是否真的有改進名稱的改進？鑑於其主要是爲了確定誰實現了評估，而不是其員工的經理。 – abichango

據推測，經理將是另一個員工記錄的ID。劃掉我原來的名單。 –

主要的想法是，你不想重複字符串文字

所以，如果你有

id Department 
    1 Sales 
    2 IT 
    3 Admin

，而不是重複Sales很多時候你只用1這是小這樣的事情也變得更快。

其次，如果你有用戶

id user 
    1 Jhon Alexander 
    2 Maria Jhonson

如果Jhon決定改變了他的名字，那麼你將必須檢查所有表並更改名稱。如果兩個人有相同的名字，你就不知道你在評估哪一個，也有問題。

所以去分離表和使用ID。

來源

2016-10-20 20:00:11

我現在看到重複的字符迴避，有道理，關於第二部分，我剛剛編輯了我的問題，澄清了一點，然而我會爲他們使用另一個表。 – abichango

是一樣的，正如我所說的事情發生變化，部門更名，部門移動。只是最佳做法。你需要學習normalize db。但是如果你的問題是關於規模的話，就像科裏所說的8000沒有什麼關係，我每天插入100萬，而只是一個普通人，就像亞馬遜一樣。 –

我確實遇到了不斷變化的問題，但是就我而言，部門更改（例如，IT部門更新（至少應該是）活動目錄中的更改），則所有未來記錄都將插入新的部門或屬性發生變化，以前的記錄應保持不變，至少這就是我被要求這樣做的原因。但感謝您的建議，絕對會更多地看到Normalizing db。謝謝！ – abichango

用於評估的SQL Server數據庫設計

回答

相關問題