0

従業員が自分の rfid カードを読み取った後、複数の rfid ハードウェア デバイスからレコードを取得します。これらの記録には

  • デバイスID
  • タイムスタンプ
  • DST / 非 DST
  • UID (RFID カードの)
  • プロジェクト ID (ユーザーが選択)

このスタックオーバーフローの質問を読んだ後、データベースを設計する方法は 2 つあります。

  • イベントのようなテーブル デザインを使用する (各レコードは新しい行です)
  • タイムクロックのようなテーブル デザインを使用する (各イン/アウト ペアは新しい行です)

後者の設計を使用すると、レポート/分析が非常に簡単になります (たとえば、「x 時間以上働いた従業員は?」、「記録がない従業員は?」、「従業員あたりの合計時間は?」、...)。

オプション1

しかし、インレコードとアウト レコードの上記のすべての情報を保存する必要があるため、テーブルのデザインは次のようになります。

RecordId | EmployeeId | TimestampIn | DstIn | UidIn | ProjectIdIn | TimestampOut | DstOut |...

これは、私が必要とすることを達成するための正しい方法のように「見えません」。

オプション 2

次に、詳細について 2 番目のテーブルを使用することを考えました。

記録：

RecordId | EmployeeId | TimestampIn | TimestampOut

レコードの詳細

RecordDetailsId | RecordId | Timestamp | Dst | Uid | ProjectId

このようにして、必要に応じて詳細にアクセスできますが、レコード テーブルで直接基本的な計算を行うことができます。

オプション 3

3 番目のオプションは、イベント テーブルを使用することです。

RecordId | EmployeeId | Timestamp | Dst | Uid | ProjectId | In/Out

これは間違いなく機能しますが、後で分析/レポートするのが難しくなります (上記を参照)。

したがって、私の質問は次のとおりです。上記の設計のいずれかが私の問題の「ベスト プラクティス」と見なされますか?また、オプションの 1 つを使用する必要がありますか? オプション1は期間などを計算する方法では良さそうに見えますが、追加の列を追加する必要がある場合、これは混乱してしまうのではないかと心配しています.

注: レコードがイン/アウトされているかどうかは、従業員が最後に行ったエントリによって決定されます。イン レコードの場合 (オプション 1/2 でアウトが空)、アウト エントリになります。

4

2 に答える 2

1

これがどれほど役立つかわかりませんが、私はこのように行きます。

    Employee
    PK EmpId | Name | ect..

    EmpDevice
    PK EmpDeviceId | FK EmpId | FK DeviceId | ActiveFrom | ActiveTo

    Device
    PK DeviceId | FK EmpDeviceId | Name | Serial Number | ect..

    EmpProj
    PK EmpProjId | Fk ProjectId | Fk UserId | ActiveFrom | ActiveTo

    Event
    PK EventId | Fk DeviceId | Timestamp | Status

従業員がサインインするたびにこのデータが繰り返されるため、イベントテーブルをできるだけ小さくしたいと思います。つまり、他のすべてを分離する必要があります。

  • デバイスのキーを取得し、必要に応じて従業員とプロジェクトに参加してクエリを実行します。
  • ビット値である「ステータス」列。1/0 はイン/アウトを表します。
  • DST は、必要に応じて導出できます。
  • 従業員に割り当てられたデバイス。従業員がデバイスを頻繁に変更する場合は、ジャンクション テーブル「EmpDevice」を使用できます。
  • プロジェクトの上記のポイントと同じです。
于 2013-11-06T11:49:59.177 に答える