per_times
180
(const or define)
user_id,life,expired
1,10,2011-05-29 07:49:00
(table user_life)
now
2011-05-29 07:45:00
expired - now
240
(sec.)
remaining
e.g.
_life = ceil((expired - now)/per_times) ※切り上げる。負は影響ないけど-1.9切り上げは-1ですよ、一応。
life - ((_life < 0) ? 0 : _life))
よくあるソーシャルアプリの体力に関して、実行毎にexpiredにper_timesを加算して更新することでlifeに対しての残が求まるという仕様の例。
DATETIMEが急にTIMESTAMPになってるとか細かいことは無視してください。
こういう値は固定値で持っておくとデータ処理が複雑になったり、意図しない値になったり、不必要なデータを記録し続けたり、更新処理が無駄に発生しかねないのでそういう仕様にしておくのが個人的には良いと思う。
もちろんテーブルはこのために正規化しておくべきだね!
間違ってもユーザマスタに持つことは避けたい。
もっと賢い方法もあるのかもしれないけど、これがオレ仕様の限界w
180
(const or define)
user_id,life,expired
1,10,2011-05-29 07:49:00
(table user_life)
now
2011-05-29 07:45:00
expired - now
240
(sec.)
remaining
e.g.
_life = ceil((expired - now)/per_times) ※切り上げる。負は影響ないけど-1.9切り上げは-1ですよ、一応。
life - ((_life < 0) ? 0 : _life))
よくあるソーシャルアプリの体力に関して、実行毎にexpiredにper_timesを加算して更新することでlifeに対しての残が求まるという仕様の例。
DATETIMEが急にTIMESTAMPになってるとか細かいことは無視してください。
こういう値は固定値で持っておくとデータ処理が複雑になったり、意図しない値になったり、不必要なデータを記録し続けたり、更新処理が無駄に発生しかねないのでそういう仕様にしておくのが個人的には良いと思う。
もちろんテーブルはこのために正規化しておくべきだね!
間違ってもユーザマスタに持つことは避けたい。
もっと賢い方法もあるのかもしれないけど、これがオレ仕様の限界w