MySQLに対し、過去のデータを保存するにはどうすれば…
- 評価
- クリップ 0
- VIEW 830
退会済みユーザー
現在、休暇管理表を作っていますが、MySQLのデータベース構造について悩んでいます。
12日間の勤怠状況のレコードを作り、PHPからインプットした勤怠データを直接データベースに保存するやり方をしています。
今の状態では勤怠データを上書きしかすることができません。過去のデータをどう保存し、管理するかを悩んでいます。以下が私なりに考えたER図です。
【ER図の説明】
テーブル別
users_info： ユーザー情報。user_idがメールアドレスとして想定しています。
days_record： days_recordテーブルのカラムには日付を入れるつもりでいます。（例：05月16日(月)
attendance_record： 休日、出勤、有給休暇と項目準備し、これをattendance_recordテーブルのカラムには勤怠状況を入れるつもりでいます。整数型にしてる理由は、文字列型を入れるのは非効率的だあり、容量もとるからです。最初から決まった項目ならば、休日、出勤、有給休暇それぞれに1,2,3と条件で数字を割り当てる方法が効率的だと判断したからです。
以上を踏まえて質問…
MySQLで過去のデータをも保存できるテーブルの構成がわかる方、ご教授ください。
経験豊富な方であれば、以上のER図を見て、結構カオスな状況に見えるかと思います。
ぶっちゃけ根本的に指摘してもかまいませんので、考えがある方、お願いします。
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
checkベストアンサー
+4
12日間というのは直近で12日間ということでしょうか。
そこらへんの意図がわからなかったのですが、単純に過去のデータも保存したいということであれば、次のようなテーブル構成で良いかなと思います。
users_infoテーブル
現状維持
days_recordテーブル
廃止（日付を日本語で保持する意味がわかりません）
attendance_recordテーブル
user_id … users_infoとリンク
date … 日付
status … 勤怠状況 status_master にリンク
status_masterテーブル
status … 勤怠状況 attendance_record とリンク
word … 日本語名（休日、出勤、有給休暇）
つまり１ユーザー、１日付ごとに１レコード作る感じです。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
+1
days_recordとattendance_recordの日付をDate型にするだけでも良いかと思います。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
2016/05/16 14:51 編集
> 廃止（日付を日本語で保持する意味がわかりません）
PHP側で日付を指定してMySQLに保存させるためです。
(GW、お盆、年末年始)若干日付変わったりするため、直接PHPの方で設定し、MｙSQLに保存する仕様です。
質問…
カラム？statusはリンクするためだけにあるんですか？
statusの存在がいまいち理解できませんでした。
2016/05/16 15:01
通常の日付とは別の管理（例えば5/16なのに5/17として扱いたいとか）が必要であるなら残しておく必要はありますね。
その場合、days_recordテーブルには、attendance_recordとリンクするためのdate型のカラムが必要になり、day01～12は不要になります。
days_recordテーブル
・user_id
・date … DATE型のカラム
・date_word … 表示用の文字列
statusはそれを管理するマスターをstatus_masterとして追加しました。
このテーブルのレコード構成は、例えば、
status, word
1, 休日
2, 出勤
3, 有給休暇
…
になります。
勤怠状況の値をマスターとして管理することで、ステータスの追加や変更を容易にします。
これはデータベースの基本的な考え方のひとつと言えるでしょう。
2016/05/16 17:07
2016/05/16 17:28
しかし、どうしてもdays_recordテーブルが必要なのでしょうか？
2016/05/16 18:26
htmlやphp側で指定した日付を保存したいので、必要なのではないかと判断しました。
もしかして、他に方法があるんですか？
2016/05/16 19:25
それが最初に提示した回答です。
2016/05/16 23:43
…まだいまいちピンときませんが、上記の考えの通りやってみます！
2016/05/20 15:03
最後に質問ですが、テーブル一つにつきprimary keyがないといけないでしょうか？
2016/05/20 15:09
プライマリーキーについては必ず必要というわけでないです。
ユニークにしたいカラムに対してつければよいです。
今回の例ですとuser_idは重複するわけにはいかないのでキーにする必要があります。