數據庫設計 - 員工時鐘輸入和輸出系統

我擔心兩件事情：

如果員工忘記從昨天的時鐘輸出「，他們有「時鐘在」今天，它應該標誌經理。
工作人員可能會隨着時間的推移工作，例如：時鐘週一上午11:00至週二上午01:30（午夜之後）。我不希望系統認爲工作人員已經忘記了計時。
- 工作人員可能每天多次計時進入和計時。

如何解決這個問題，有什麼可以對數據庫設計加以改進？

人員表：

+-------------+--------------+------+-----+---------+----------------+ 
| Field  | Type   | Null | Key | Default | Extra   | 
+-------------+--------------+------+-----+---------+----------------+ 
| id   | int(11)  | NO | PRI | NULL | auto_increment | 
| name  | varchar(50) | NO |  | NULL |    | 
| password | varchar(50) | NO |  | NULL |    | 
| hourly_rate | decimal(6,2) | NO |  | NULL |    | 
+-------------+--------------+------+-----+---------+----------------+

計時錶：

+----------------+----------+------+-----+---------+----------------+ 
| Field   | Type  | Null | Key | Default | Extra   | 
+----------------+----------+------+-----+---------+----------------+ 
| id    | int(11) | NO | PRI | NULL | auto_increment | 
| staff_id  | int(11) | NO |  | NULL |    | 
| clock_in_date | datetime | NO |  | NULL |    | 
| clock_out_date | datetime | NO |  | NULL |    | 
+----------------+----------+------+-----+---------+----------------+

來源

2012-03-06 I' ll-Be-Back

你的數據庫設計似乎罰款。它應該只記錄進出時間。應用程序中的其他位置應該編寫業務規則。 You may read this article on wikipedia關於分離問題。

來源

2012-03-06 13:36:26 Roger

這從域的角度來看並不完全正確。

爲了審覈或故障排除，需要掛鐘或打孔/打孔。因此，您需要爲所有員工存儲個人拳擊歷史記錄。

你的情況下的時鐘表可能是派生的數據。

的計時錶應該是

+----------------+----------+------+-----+---------+----------------+ 
| Field   | Type  | Null | Key | Default | Extra   | 
+----------------+----------+------+-----+---------+----------------+ 
| id    | int(11) | NO | PRI | NULL | auto_increment | 
| staff_id  | int(11) | NO |  | NULL |    | 
| clock_type  | int(1) | NO |  | 0  | 0-in, 1-out | 
| clock   | datetime | NO |  | NULL |    | 
+----------------+----------+------+-----+---------+----------------+

來源

2012-03-06 13:37:24 shikhar

這會增加不必要的複雜性，以確定該人是否在重新計時之前計時了。原始設計更好。儘可能避免使用EAV表格。 – HLGEM 2012-03-06 14:53:16

不，原來的那個變得非常複雜，我從經驗中講述了這一點。任何新手都會接受最初的設計，但沒有注意到db不應該給你報告你的願望，而是以最少的冗餘形式提供數據。您可以保留一個冗餘的統一報告表（輸入 - 輸出）以便快速檢索。 – shikhar 2012-03-06 16:19:47

@shikhar你可能是對的。看看我發佈的這個問題。 http://stackoverflow.com/questions/12632302/design-to-represent-employee-check-in-and-check-out – 2012-09-28 01:16:50

你需要允許NULL上clock_out_date。這樣，您可以在發生支票時記錄支票，只需保留clock_out_dateNULL以指示用戶尚未檢出。

如果您計劃支持每次活動/每天的多重簽入/簽出，那麼您還需要在時鐘表中設置活動/日期ID列，以便按事件/日期對簽入進行分組。如您所述，該日期不能用於分組簽到午夜。我們使用event_id，但也許你想要一個payroll_date。

我對類似的系統使用相同的時鐘表結構。它已經投產一年了，我不會改變一件事情。我們以UTC存儲所有時間。

請注意，我們不使用此係統進行工資覈算，並且薪資系統可能存在重大審計要求。

來源

2012-03-06 14:53:29

同樣時鐘日期不應該被允許爲空 – HLGEM 2012-03-06 14:55:27

@HLGEM，感謝澄清。 – 2012-03-06 15:06:27

感謝您的建議。有時候，工作人員可能會每天檢查（任何隨機原因） - 所以你的意思是我需要添加'week_day'字段？工作人員可能會隨着時間的推移工作，例如：時鐘週一上午11:00至週二上午01:30（午夜後）。這將如何工作。 – 2012-03-06 15:07:51

我看不出您的設計有什麼問題，因爲我看到了需求不足的問題。您需要更好地定義何時經理被更改以解釋多天的轉變。也許最好的規則是，如果有人沒有24小時退出計時器，或者如果他們第二次嘗試計時，主管會收到通知。如果時鐘丟失，您可能還需要數據庫上的觸發器，以防止時鐘進入。或者您可以允許時鐘進入，並將缺少的時鐘發送給主管進行操作。

有一件事你特別需要的是審計（一個單獨的表），這樣你可以看到誰改變時記錄。你是否能夠分辨誰改變了記錄，以及在有人問時間的情況下舊值是多少。

時間計時（我假設他們會根據計時工作時間獲得報酬）是一項需要嚴格內部控制的活動（在數據庫級別而不是在應用程序中！如果您試圖在內部控制中執行操作防止欺詐行爲）。沒有人應該直接訪問該表。他們應該只能通過一個存儲過程進行更改，這個存儲過程確切地說明了他們可以做什麼。

您可能想爲副監事非監事的具體規則。一般來說，任何與時間相關的事情只能由事後的主管改變。我會有一個強制執行此操作的觸發器，輸入時間表的人員只應允許更改數據中的時鐘，並且只有在它爲空時才允許。所有其他更改應該來自該人員的主管。所以你可能需要一個表來存儲組織結構或者至少一個顯示工作人員監督人員的字段。

如果人們會基於時鐘插件和oputs被poaid，thenyou可能要檢查你的會計人員和審計師beofre敲定業務規則。內部控制這種事情可能是非常複雜和棘手的，以獲得正確的。

我看到的一個設計問題是小時費率列，它會隨着時間的推移而變化，您希望能夠說明（特別是如果費率在某個支付週期中由於某種原因發生變化），所以我會中斷這出到了一個相關的表格。同樣，這張表的權利需要嚴格執行。沒有人嘲笑人力資源人員應該能夠將數據輸入小時費率字段。

來源

2012-03-06 15:04:28 HLGEM

什麼是蠕蟲的大規模CAN你打開這裏的隊友。在爲一家只有時鐘系統的公司工作之後，這是我永遠不會想再做的事情！

我意識到我的回答是大大的概念和問題的正常範圍之內解決一些問題，但是這是爲了勾勒數據庫設計和結構概念，這種類型的應用。這些信息來自我在這方面所做的最近的專家發展，所以它不是完全假設的，而是在實踐中證明的。

當你正在尋找這種類型的系統你最好最初使用指標作爲標誌，這通常是對拳每條記錄進行比較的數量。比較1000名員工的每個記錄並不是最好的事情！

例如，如果用戶在24小時內有8次拳擊（一天的開始，早上休息開始，早上休息結束，午餐開始，午餐結束，下午休息開始，下午休息結束和一天結束），您可以確定在此期間不可能有錯過的拳擊和加班已經發生，但是如果在24小時期間（白天開始，早上休息開始，早晨休息結束，午餐開始，午餐結束，下午7次打孔打破開始和結束的一天）你知道一拳是失蹤和該人忘記了一天的時鐘。注意下午休息時間不在那裏。

然而，這並非完全的證明，只是提供一個參考用途，您將需要一個排班比較拳，以確保實際上什麼也沒有錯過。因爲可能午餐結束和下午休息結束都錯過了留下6次拳擊，您可以設置您的代碼來標記任何不是該員工的拳擊次數的任何數字。當你被標記時，你會在那段時間內對該員工進行實際比較，以確定實際發生的事情和錯過的事件。

這並不意味着你不比較的所有記錄，但事情是根據員工數量可能會導致一些大問題，每個記錄上做精確比較，這是它通常是爲更大的數字更好的員工使用2臺服務器，1臺僅用於數據收集和接口，另一臺用於運行比較流程。

正如我提到的，對於這種類型的應用，並與不同的時間表工作，你還需要看看拿着換檔規律來比較。您需要爲每位員工提供一個填充記錄，在換班開始前和換班結束後給予相同的時間。這意味着超過1個時間段的加班可能性會很小。其基本的表現公式是非常簡單的：在換檔時數 - 39小時/ 2 =時間填充

現在，您之前和該用戶的排班後放置時間填充。但您仍然需要應對換班，換班或超過24小時輪班。這是真正棘手的地方。你會希望看一下持有重疊次數的表格（填充，移位和拳擊），然後可以對照日程表的任何未來調整進行調整，因爲事後更改在考勤中並不少見。

現在您還需要爲病假和假期保留缺席時間表，因此這些數據通常需要在打卡/打卡表中標記，因爲這是您比較的內容。當某個標記被設置爲一段時間時，可以跳過該記錄進行比較，並在報告中留下備註，而無需運行其他操作來檢查該記錄。

幾乎在日結束，注意你如何需要你正常的日期/時間約定忘記測量這個對一系列的變量？更不用說在多個日期有效地工作了？因此，您通常最好只使用dd/mm/YYYY hh：mm：ss的開始和結束時間進行工作，因爲測量使用UNIX時間來計算已經過了多長時間。在說可以審計時，大多數系統都需要「日期戳記」，因此在發佈報告時可能需要對服務器端進行處理。

最後，我還建議保留一個結果表，這樣會給每個用戶的報表結果，這種方式當你想提供歷史記錄時可以動態生成文檔，但是你不必浪費處理能力每次請求報告時比較記錄。

我希望這有助於！

來源

2012-03-06 15:17:14 Ryan

數據庫設計 - 員工時鐘輸入和輸出系統

回答

相關問題