前の職場の同僚から連絡をうけた『勤怠管理システム』について、
ざっと要件を整理しながらデータベースのテーブルを考えてみる事になったので、
備忘録がてらこちらにも投稿しておきます。
あくまで現段階では仮作成なので、
コードを書きながらまずいとなったら変更する可能性大です。
関連記事
勤怠管理システム ユーザーテーブル
まずは勤怠管理システムを使うユーザーのテーブルを考えてみまして、
- id
- 氏名
- 社員番号
- 部門(FK)
- 役割
- 表示/非表示
- 表示順
の7つの列でいけるかなと思っています。
氏名と社員番号は1対1で紐づくので同じテーブルにして、
部門は、部署異動がありえるので別テーブル(departments)と1対多のリレーションを想定しています。
一般や部門管理者など、役割によって表示させる機能を切り替えたいので、
役割はenumでもいいのですが、tiyIntegerとしています。
表示非表示は、退職もありえるので非表示フラグを持たせて、
表示順は必要かどうか微妙なところではあるのですが、
表示順を変えたいと言われた時に対応しやすいように先に追加しています。
勤怠管理システム 部門テーブル
部門はシンプルに、
- id
- 部門名
- 表示順
の3つのみ。
部門はおいおい増える可能性もないこともないだろうということで、別テーブルにしています。
表示順はユーザーテーブル同様、念の為の列になります。
勤怠管理システム シフトテーブル
続いてシフトのタイプを管理するテーブル。
こちらもシンプルに下記5つのみ。
- id
- シフトのタイプ
- 表示/非表示
- 時間
- 表示順
夜勤や短時間などシフトのタイプが100種類くらいあるそうで、
対応表を頂き次第にらめっこしながらダミーデータとして入力していく予定です。
部門によって表示必要なシフトが違うかも、とも思うので、
ヒアリング後部門ごとに表示を切り替える必要がでてくれば、
部門テーブルとリレーションする必要がありそうです。
勤怠管理システム タイムテーブル
こちらが実際に年月日、氏名、シフトのタイプなどが入ってくるテーブルになります。
- id
- 年月日
- ユーザー情報(FK)
- シフトのタイプ(FK)
- ロック
の5つの情報のみ。
年月と日をわけるかどうか悩んだのですが、
レコードの数的にそこまで多くはならないと思われるので、
まとめて1つの列としています。
データ量を考えるに、
- 1人あたり約30件
- 100人とすると 約3,000件/月
- 1年とすると 約12,000件
- 10年で 約12万件
ということで、数十万件くらいの規模であればMySqlでガリガリやって問題ないかなと思われます。
もし重くなったら過去データを別テーブルなりに移す必要が出てくるかも知れません。
パーテーションわけるまでもないのではと思ってはおります。
ロックについては、一度申請した後は変更不可としておいて、
申請->承認された内容のみ変更できるようにするためのフラグになります。
勤怠管理システムのテーブルを考えてみて
今の所できるだけシンプルに抑えつつ、
後から増えたり変更がきそうな項目は予め、表示非表示なり表示順なりでカバーできるかなと思いつつ、
並行で現地から届いている資料とにらめっこし、修正があればガリガリと修正して早めに見積もり提出できるよう対応してまいります。
この記事へのコメントはありません。