- PR -

日数を元に処理をしたい。

投稿者投稿内容
NAL-6295
ぬし
会議室デビュー日: 2003/01/26
投稿数: 966
お住まい・勤務地: 東京
投稿日時: 2007-07-05 13:12
NAL-6295です。

社員マスタ
PK社員番号
・名前
・入社日
・有給付与対象月

有給ルールマスタ
PK勤続年数
・有給付与数

有給テーブル
PK社員番号
PK有給付与年月日
・有効期限
・残有給日数

で、毎年、有給付与対象月になったら、
入社日から勤続年数を計算して、
有給ルールマスタにある有給付与数分付与してあげる。

付与された有給は有給テーブルで管理する。

というのはどうでしょう。
オウドー
ベテラン
会議室デビュー日: 2007/06/05
投稿数: 59
投稿日時: 2007-07-05 14:08
引用:

NAL-6295さんの書き込み (2007-07-05 13:12) より:
NAL-6295です。

社員マスタ
PK社員番号
・名前
・入社日
・有給付与対象月

有給ルールマスタ
PK勤続年数
・有給付与数

有給テーブル
PK社員番号
PK有給付与年月日
・有効期限
・残有給日数

で、毎年、有給付与対象月になったら、
入社日から勤続年数を計算して、
有給ルールマスタにある有給付与数分付与してあげる。

付与された有給は有給テーブルで管理する。

というのはどうでしょう。



お返事遅くなりました。有休付与対象月とありますが日にち単位では対応してないんですか。
流れなどはだいたい分かりました。ありがとうございます。

引用:

チェックする順序だけの問題では?後方から順にチェックして、真になって処理したらbreakして以降はskipというだけ・・。

というか普通は「有給マスタ」って勤続年数と付与日数だけでいいような・・。社員マスタの有給付与月(あくまでも「月だけを保持」)が処理月と等しかったら勤続年数から付与日数を取ってくるとかいうロジックじゃダメですか?



そうですね。逆から条件分岐をかけてやると成功しますね。
しかし、ソースがかなり冗長になるかと思っております。
それに、例えば、ボタンが押されたら有休計算というケースがあるとします。
その時、7年働いてる社員はボタンを押すたび6年6ヵ月を真で返すのでどうかとは
思うんですがいかがでしょうか。

オウドー
ベテラン
会議室デビュー日: 2007/06/05
投稿数: 59
投稿日時: 2007-07-05 14:08
引用:

NAL-6295さんの書き込み (2007-07-05 13:12) より:
NAL-6295です。

社員マスタ
PK社員番号
・名前
・入社日
・有給付与対象月

有給ルールマスタ
PK勤続年数
・有給付与数

有給テーブル
PK社員番号
PK有給付与年月日
・有効期限
・残有給日数

で、毎年、有給付与対象月になったら、
入社日から勤続年数を計算して、
有給ルールマスタにある有給付与数分付与してあげる。

付与された有給は有給テーブルで管理する。

というのはどうでしょう。



お返事遅くなりました。有休付与対象月とありますが日にち単位では対応してないんですか。
流れなどはだいたい分かりました。ありがとうございます。

引用:

チェックする順序だけの問題では?後方から順にチェックして、真になって処理したらbreakして以降はskipというだけ・・。

というか普通は「有給マスタ」って勤続年数と付与日数だけでいいような・・。社員マスタの有給付与月(あくまでも「月だけを保持」)が処理月と等しかったら勤続年数から付与日数を取ってくるとかいうロジックじゃダメですか?



そうですね。逆から条件分岐をかけてやると成功しますね。
しかし、ソースがかなり冗長になるかと思っております。
それに、例えば、ボタンが押されたら有休計算というケースがあるとします。
その時、7年働いてる社員はボタンを押すたび6年6ヵ月を真で返すのでどうかとは
思うんですがいかがでしょうか。

マーサ
ベテラン
会議室デビュー日: 2004/11/26
投稿数: 87
投稿日時: 2007-07-05 14:47
引用:

オウドーさんの書き込み (2007-07-05 14:08) より:

有休付与対象月とありますが日にち単位では対応してないんですか。


例として月で書いているのだと思います。
日にちで対応したければ、その様に設計すれば良いと思いますが。

引用:

それに、例えば、ボタンが押されたら有休計算というケースがあるとします。
その時、7年働いてる社員はボタンを押すたび6年6ヵ月を真で返すのでどうかとは
思うんですがいかがでしょうか。


「有給計算年月日」の様な項目を付け足してチェックすると言うのはどうでしょうか?
#最終更新日付みたいなものですね。
オウドー
ベテラン
会議室デビュー日: 2007/06/05
投稿数: 59
投稿日時: 2007-07-05 15:00
引用:

マーサさんの書き込み (2007-07-05 14:47) より:


例として月で書いているのだと思います。
日にちで対応したければ、その様に設計すれば良いと思いますが。




そうですね。日にちも変わらないので日にちでしてみたいと思います。
引用:

「有給計算年月日」の様な項目を付け足してチェックすると言うのはどうでしょうか?
#最終更新日付みたいなものですね。


なるほど、一度更新したものにフラグを立たせそれを行っても追加されないようにする。ってことかな?
オウドー
ベテラン
会議室デビュー日: 2007/06/05
投稿数: 59
投稿日時: 2007-07-05 17:15
引用:

NAL-6295さんの書き込み (2007-07-05 13:12) より:
NAL-6295です。

社員マスタ
PK社員番号
・名前
・入社日
・有給付与対象月

有給ルールマスタ
PK勤続年数
・有給付与数

有給テーブル
PK社員番号
PK有給付与年月日
・有効期限
・残有給日数

で、毎年、有給付与対象月になったら、
入社日から勤続年数を計算して、
有給ルールマスタにある有給付与数分付与してあげる。

付与された有給は有給テーブルで管理する。

というのはどうでしょう。




NAL-6295さんお返事ありがとうございます。

まぁ、即興で作られたと思いますが一つ質問させていただきます。

上記の簡易テーブルにて”有休付与対象月”とございますがこの列の「型」は何をお考えでしょうか?私は、今現在入社日をDateTime型にしております。

仮に、”有休付与対象月”をDateTime型にするとデフォルトで年まで入ってしまいます。

いかがおかんがえでしょうか?それとも、私が変なことを申しているだけかもしれません。
ぶさいくろう
ぬし
会議室デビュー日: 2005/11/22
投稿数: 1232
お住まい・勤務地: 川崎市(は俺も含めてロクな人間が住んでないよw)
投稿日時: 2007-07-05 17:24
引用:

オウドーさんの書き込み (2007-07-05 17:15) より:
引用:

NAL-6295さんの書き込み (2007-07-05 13:12) より:
NAL-6295です。

社員マスタ
PK社員番号
・名前
・入社日
・有給付与対象月

有給ルールマスタ
PK勤続年数
・有給付与数

有給テーブル
PK社員番号
PK有給付与年月日
・有効期限
・残有給日数

で、毎年、有給付与対象月になったら、
入社日から勤続年数を計算して、
有給ルールマスタにある有給付与数分付与してあげる。

付与された有給は有給テーブルで管理する。

というのはどうでしょう。




NAL-6295さんお返事ありがとうございます。

まぁ、即興で作られたと思いますが一つ質問させていただきます。

上記の簡易テーブルにて”有休付与対象月”とございますがこの列の「型」は何をお考えでしょうか?私は、今現在入社日をDateTime型にしております。

仮に、”有休付与対象月”をDateTime型にするとデフォルトで年まで入ってしまいます。

いかがおかんがえでしょうか?それとも、私が変なことを申しているだけかもしれません。


おまえさんの投稿は丸投げすぎ。
わかっていないのは悪いことではないがそれにしても努力の形跡が見られず
読んでいて不快だった。

>まぁ、即興で作られたと思いますが一つ質問させていただきます。

まぁってなんだ。と思ったのは俺だけではあるまい。

じゃんぬ御大は「有給更新月」で管理せよと言っているのに
ぽぴ王子氏の出した例はちょっと悪かったかな。と思ったんだが日付まで管理対象なのか。

フツーは会社の締め日で付与されると思うんだが。
おそらくそれを見越しての皆さまさまの回答なのでそのへんは自分でカスタマイズせぇよ。
頭使わないと成長しないのが人間。
ぶさいくろう
ぬし
会議室デビュー日: 2005/11/22
投稿数: 1232
お住まい・勤務地: 川崎市(は俺も含めてロクな人間が住んでないよw)
投稿日時: 2007-07-05 17:27
引用:

オウドーさんの書き込み (2007-07-05 11:54) より:
45行ですか…何分、新人なもんで上手く設計できないです。(まぁ言い訳ですが。)
正規化、リレーションともに理解をしておりますがなんてゆうんでしょうか。
それをするためのベース(テーブル)ってのが上手く作成できないんですよね。

話は戻りますが”列45”じゃなく”行45”ですか。


残念なことにこれくらいのテーブル設計ができなきゃリレーションも正規化も理解できていない。
うちの新人に最近似たシステムを個々に作らしたがほとんどのやつらがNAL-6295氏のようなテーブル設計をしていた。
そもそも列に冗長に持つという考えからして第三正規化とか知らないってことじゃん。

スキルアップ/キャリアアップ(JOB@IT)