mysqlでシンプルな勤怠管理システムのデータベース設計を実現

勤怠テーブルには、attence_id、employee_id、check_in、check_out の 4 つのフィールドが含まれている必要があります。これらのフィールドにはすべて厳密な型と制約が必要です。 employee_id は外部キー、attence_id は自動インクリメントされる主キーです。従業員テーブルには ENUM ステータス フィールドが追加され、インデックスが作成されます。 check_in/check_out は片側 NULL を許可しますが、完全に空にすることはできません。労働時間やステータスなどの派生値はリアルタイムで計算されなければならず、冗長なフィールドは禁止されなければなりません。 3 つの端のタイムゾーンを統一する必要があります。

勤怠テーブルには、 attendance_id 、 employee_id 、 check_in 、およびcheck_out

1 つは必須であり、そうでないと「パンチ タイムの計算」と「従業員のディメンション統計」をサポートできません。 check_inとcheck_out DATETIME型 ( DATEやTIMESTAMPではない) を使用する必要があります。そうしないと、昼休み後に 2 回チェックインする、複数日にまたがって残業するなどのシナリオでエラーが発生します。 ダーティ データを避けるために、 employee_id従業員テーブルに関連付ける外部キーとして設定する必要があります。 attendance_idは自動インクリメント主キーとして設定することが推奨されますが、UUID は推奨されません。挿入パフォーマンスが悪く、MySQL 8.0 より前の UUID のソート効率は非常に非効率的でした。

従業員テーブルはstatusフィールドを予約し、デフォルト値'active'を設定する必要があります。

実際の運用保守では、従業員が退職したが勤怠記録を残さなければならないという状況に遭遇することがよくあります。従業員の記録が削除されると、過去の勤怠記録は「ゴーストクロック」になります。無効化されているだけで削除されていない場合、 statusフィールドがなければ、コメントまたは追加のテーブル マークのみに依存することになり、確認するのが面倒でエラーが発生しやすくなります。

• スペルミスを防ぐには、 statusタイプにENUM('active', 'inactive', 'on_leave')を使用する方がVARCHARより安全です。
• インデックスを追加します:

   CREATE INDEX idx_employee_status ON 従業員(ステータス);

• 当月の従業員の出席状況をクエリする場合は、テーブルに結合してフィルタリングしたり、サブクエリを書き込んだりせずに、直接WHERE e.status = 'active' 。

check_inとcheck_out NULL を許可しますが、ビジネス層はそれらのうち 1 つだけを空にできるように制御する必要があります。

早退、打刻忘れ、設備故障などはいずれも一方的な損失につながります。データベース レベルを強制的に空以外にすることはできません。そうでない場合、エントリは失敗します。ただし、両側を空のままにすることはできません。その場合、レコードは無意味になります。

• テーブルの作成時に次のように定義します。

  チェックイン日時 NULL、チェックアウト日時 NULL

• トリガーまたはアプリケーション ロジックによるチェック: check_in IS NULL AND check_out IS NULLは許可されません
• 労働時間を計算するときは、 TIMESTAMPDIFF直接記述せず、最初に判断を追加します。

   IF(チェックインは NULL ではなく、チェックアウトも NULL ではありません、TIMESTAMPDIFF(HOUR、チェックイン、チェックアウト)、NULL)

「遅刻したかどうか」などの派生フィールドを出席シートに保存しないでください。

遅刻ルールは頻繁に変更され (柔軟な 15 分、休日の調整、部門の差別化など)、フィールドをハードコーディングするとルールが変更されるたびにALTER TABLEが完全に更新されるため、リスクが高く時間がかかります。

正しいアプローチは、ビューまたはクエリ時の計算を使用することです。

選択 *、
  場合 
    WHEN TIME(チェックイン) > '09:15:00' THEN '遅刻'
    ELSE '定刻'
  END AS 出席状況
出席から
JOIN 従業員 e ON a.employee_id = e.employee_id;

複雑なルール (部門ごとに異なるパンチイン時間を設定するなど) の場合は、メイン テーブルのフィールドにルールを詰め込むのではなく、関連する構成テーブルを使用します。

実際のデプロイメント中に最も見落とされやすい側面は、タイム ゾーンの処理です。MySQL サーバー、接続クライアント、およびアプリケーション コードのタイム ゾーンが一致していないため、 NOW()挿入時間が現地時間よりも数時間遅れる/早くなります。オンラインにする前に、必ずSYSTEMに設定するか、明示的に08:00指定してください。デフォルト値に依存しないでください。

以上がmysqlでシンプルな勤怠管理システムのデータベース設計を実現の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。