データベース設計 - 従業員クロックインイン/アウトシステム

Question

従業員クロックインイン/アウトシステム（ウェブサイト）を開発したいと思います。

私は心配二つのことだ：スタッフは昨日から「クロック出力」に忘れてしまったと、彼らはマネージャーに「時計」では、今日、それが必要旗を持っている場合は

• を。

• スタッフは時間の経過とともに機能するかもしれません。たとえば、時計：月曜日午前11時から午後1時30分（真夜中後）。私はシステムがthayスタッフがクロックアウトするのを忘れてしまったと思ってはいけないと思っています。

  • スタッフは1日に何回もクロックしたりクロックを取ります。

はどのようにこの問題を解決し、データベースの設計にどのように改善することができますか？

スタッフテーブル：テーブルを計時

+-------------+--------------+------+-----+---------+----------------+ 
| 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 |    | 
+----------------+----------+------+-----+---------+----------------+ 

Answer 1

データベース設計は罰金です。それは、インタイムとアウトタイムを記録するだけです。アプリケーションのどこか他の場所で、ビジネスルールをプログラムする必要があります。懸念の分離に関するYou may read this article on wikipedia

Answer 2

これは、ドメインの観点からは完全には正しくありません。

監査目的またはトラブルシューティングのために、クロックインまたはアウト/パンチが必要です。 したがって、すべての従業員に個別のパンチ履歴を保存する必要があります。

あなたのケースのクロックテーブルは派生データである可能性があります。

クロッキングテーブルには、あなたがclock_out_dateにNULLを許可する必要があります

+----------------+----------+------+-----+---------+----------------+ 
| 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 |    | 
+----------------+----------+------+-----+---------+----------------+ 

Answer 3

でなければなりません。これにより、チェックインが発生した時点で記録することができ、ユーザーがまだチェックアウトしていないことを示すだけでclock_out_dateNULLのままにしておくことができます。

イベント/日ごとに複数のチェックイン/アウトをサポートする予定の場合は、イベント/ 1日ごとにチェックインをグループ化できるように、クッキングテーブルにイベント/ ID ID列も必要です。あなたが注意したように、この日付は、深夜に及ぶチェックインをグループ化するために使用することはできません。 event_idを使用しますが、おそらくpayroll_dateが必要です。

私は、同様のシステムで同じクロックテーブル構造を使用しています。それは1年間の生産であり、私は事を変更しません。私たちはすべての時間をUTCで保存します。

このシステムは給与計算には使用しません。給与計算システムには重要な監査要件があることに注意してください。

Answer 4

デザインに問題はありません。デザイン要件に問題があるとは限りません。あなたは、複数の日に渡るシフトを考慮してマネージャーが変更されたときのより良い定義が必要です。おそらく、最善のルールは、誰かが24時間クロックアウトしていない場合や、2度目にクロックをかけようとすると、スーパーバイザに通知されるということです。また、クロックが欠落している場合にクロックを許可しないデータベース上のトリガーが必要な場合もあります。または、クロックを許可して、不足しているクロックアウトをスーパーバイザに送信してアクションを実行することもできます。

あなたが特に必要とするものは、誰がレコードを変更したかを見ることができるように監査（別のテーブル）です。あなたは誰がレコードを変更したのか、誰かの時間についての質問の場合には古い値が何であるかを知ることができるようになりませんでした。

タイムクロッキング（時間を基準にして払い戻されることになります）は、深刻な内部コントロールが必要なアクティビティです（データベースレベルではアプリケーションではありません）。誰もがテーブルに直接アクセスする必要はありません。彼らは、できることを正確に指示するストアドプロシージャを介してのみ変更することができます。

スーパーバイザの非監督者に固有のルールが必要な場合があります。一般的に時間関連のものは、その事実の後にその人の上司によってのみ変更されることが許されるべきです。私はこれを強制するトリガーを持っているでしょう、タイムシートに入る人は、データが入っている時計だけを変更し、それがヌルである場合にのみ変更するようにしてください。他のすべての変更は、その人の監督からのものでなければなりません。だから、あなたは組織構造を保管するためのテーブルが必要かもしれませんし、少なくともスタッフの監督者が誰であるかを示すフィールドが必要かもしれません。

人がクロックインとアウトプットに基づいて賞金を支払う場合は、会計上の人とその監査人がビジネスルールを確定することを確認することをお勧めします。このようなことに対する内部的な矛盾は、正確にするには非常に複雑で厄介なことがあります。

私が見ている1つの設計上の問題は、時間の経過とともに変化します。何らかの理由でペイペリオドの途中でレートが変化した場合、そのことを伝えたいと思うでしょう。これは関連するテーブルに出力されます。繰り返しますが、この表に対する権利は厳格に強制される必要があります。 HR担当者が時間外料金欄にデータを入力できる必要があります。

Answer 5

あなたがここに開く巨大な虫の数はなんですか？システムのクロッキングだけを行っている会社のために働いた後、私は決してもう一度やりたいことはありません！

私の返信は非常に概念的であり、質問の通常の範囲外のいくつかの問題に取り組んでいますが、これはこのタイプのアプリケーションにおけるデータベース設計と構造概念を概説するためです。この情報は、私がこの分野で行った最近の専門家の発達からも得られたものであり、したがって、それは単に仮説的なものではなく、実際に実証されたものです。

このタイプのシステムでは、最初にフラグをフラグとして使用することをお勧めします。これは、一般に、すべてのレコードを比較した場合のパンチの量です。 1000人の従業員のすべてのレコードを比較するのは最善のことではありません！

たとえば、ユーザーが24時間のパンチ（開始日、朝ブレーク開始、朝ブレーク終了、昼食開始、昼食終了、午後休憩開始、午後休憩終了、および終わり）を持っている場合は、その期間中に逃したパンチがなかったと判断することができますが、24時間以内に7パンチがあれば（開始、朝ブレーク開始、朝ブレーク終了、昼食開始、昼食終了、午後休憩の開始と終わり）パンチが欠けていることを知っている人は、その日のために時計を外すのを忘れていました。どのように午後の休憩の終わりがそこにないことに注意してください。

は、しかし、これは完全な証拠はないとだけ示す基準を提供し、あなたは何が実際に見逃しなかったことを確認するためにパンチへのシフトスケジュールを比較する必要があります。ランチエンドと午後ブレークエンドの両方が両方とも6つのパンチを逃してしまった可能性があるので、その従業員のパンチの数ではないものにフラグを立てるようにコードを設定することができます。その後、実際に何が起こったのか、何が見逃されたのかを実際に比較して、その期間のその従業員の実際の比較を実行します。

この

事は、しかし、それはより多くのために、一般的に優れているところ、それはこれは、すべてのレコード上の正確な比較をしているいくつかの大きな問題を引き起こす可能性があり、従業員の数に依存している、あなたはすべてのレコードを比較しないという意味ではありません2つのサーバーを使用する従業員のうち、1つはデータ収集とインターフェイスのみ、2つ目は比較プロセスの実行です。

私はこのタイプのアプリケーションのために、言及し、様々なスケジュールで動作するように、あなたはまた、と比較してシフトスケジュールを保持を見てする必要があります。シフト開始前とシフト終了後に等しい時間を与えるパッディングレコードを各従業員に保持する必要があります。これは、1時間を超えて延長される残業の可能性が最小限になることを意味します。基本的なformularは本当に簡単です：シフトの時間数 - 24時間/ 2 =時間パディング

あなたは今、そのユーザーのシフトスケジュールの前と後の時間パディングを配置します。しかし、あなたはまだシフト交換、変更、または24時間以上のシフトを処理する必要があります。これは本当に面倒なところです。事実の変更が慣習では珍しいことではないため、スケジュールの将来の調整と調整することができる重なり合った時間（パディング、シフト、パンチ）の表を保持することを検討することが望ましいでしょう。

病欠や休暇のために欠席期間のテーブルを保持したい場合は、このデータをパンチイン/パンチアウトテーブル内に一般にフラグを立てる必要があります。ある期間フラグが設定されている場合、レコードは比較でスキップされ、追加の操作を実行しなくても確認できるようになります。

ほとんどの場合、さまざまな変数についてこれを測定するために、通常の日付/時刻の慣習を忘れる必要があります。効果的かつ効率的に複数の日付にわたって作業することは言うまでもありませんか？このため、開始時刻と終了時刻はdd/mm/YYYY hh：mm：ssだけで作業するのが一般的です。測定にはUNIX時間を使用して経過時間を計算します。ほとんどのシステムでは、監査を行うために、「日付スタンプ」レコードが必要であるため、レポートを出力するときに、このサーバー側の処理が必要になる可能性があります。

最後に、結果テーブルを保持することもお勧めします。これにより、各ユーザーのレポート結果が得られます。これにより、履歴レコードを提供する際に処理能力を浪費する必要はありませんレポートが要求されるたびにレコードを比較します。

こちらがお役に立てば幸いです。