PHPとMySQLでのシステム開発について

質問

現在PHPとMySQLである不動産システムを業務で開発しております。
ある程度の機能の実装は完了しているのですが、一点実装方法になやんでおります。

それが、不動産の新着物件の表示方法なのですが例えばなにかしら新規でDB上に物件データを登録して
あるテーブル【estate_index_table】というテーブルのあるレコード上のupdate_timeというカラムを
4月1日( フォーマットここではおいておきます）とします。
そのレコードを例えば二週間後の4月15日にその新着という表記を消したいのです。
その場合の、一般的な実装方法をしりたいのです。

現在、私が考えているのが、update_timeというカラムと同じテーブルに【estate_new_flag】というカラムをつくり
その新着フラグには1か2の論理値を格納するようにします。
フレムワークはFuelPHPを使用していますが、とりあえずビュー上でestate_new_flagが1の時は新着アイコンを表記、2の時は表記しない。

そして新着期間の2週間目に、任意のクライアントPCからその情報が閲覧できるURLにアクセスした際に、
そのレコードのupdate_timeを参照して、２週刊前ならestate_new_flagを2へとupdateする、そうでなければスルー
という処理を行う、APIを作って叩かせるといった具合です。

そのestate_new_flagは一般的な管理画面から随時任意のタイミングで新着にするというボタンをつくり
新着にするという変更をレコードに行った場合、冒頭で述べた【estate_index_table】のupdate_timeを更新するというAPIを叩きます。

これが、現在私が考えている実装方法です。どうも、考え方がシステム初心者てきな感じがしてひっかかっているのです。
理想はMySQLだけで、cronタブみたく、任意のタイミングで自動で特定のレコードを変更するような処理がいい（やってみたい）
のですが、一般的にこのような新着情報の上げ下げっていうのはどのように実装するのがベストなのでしょうか？

今回初めてDBから一人で設計してやっているので、後々になってただしい実装だったのかどうか悩むのは嫌なので
どなたかベターな方法をお教えください。
よろしくお願いします。

回答No.5

agunuz

ANo.2 です。

>update_time以外にフラグをもつ理由としては
>同一のレコードが例えば半年後あるいは一年後には
>再び、新着レコードとなる場合が多々あるということです。

すでに他の方からもツッコミがありますが、そのときには「update_timeが書き替えられて」新着として扱われるようになるというのが普通の処理です。

たとえフラグを持っていたって2週間経過後に更新するためには起点となる日付は必須ですよね。逆にその起点となる日付（日時）さえあれば、フラグなんて要らないし更新する必要もないです。

update_time以外にcreate_time（最初に作成した日時）も持っておくというならまだ理解できます。リストで「新着」と「更新」を分けて表示するケース（表示期限も別だったり）もありますので。

回答No.4

tracer

ちょっと全体がよくわかってないですが、phpに、2週間を比較するロジックを組めばいいだけのような気がしますが。
現在のタイムスタンプ(あるいはどこかに保存されているタイムスタンプ)と、DB内に格納された物件ごとのタイムスタンプの差が2週間以内なら新着表示するみたいな感じですが。もしくは、私が何か勘違いしてるかな？

$now = 現在のタイムスタンプ
$old = 物件ごとのタイムスタンプ
$def = 新着表示をはずす期間を示すタイムスタンプ

$new_flg = ($now - $old ) < $def ? true : false;

回答No.3

STICKY2006

こんばんは。

>>update_time以外にフラグをもつ理由としては
>>同一のレコードが例えば半年後あるいは一年後には再び、新着レコードとなる場合が多々あるということです。
>>そして、要は管理画面から、対象のレコードを再び新着のレコードとして扱う必要があるため、estate_new_flagという列を考えております。

ちょっと、後だしじゃんけん感がありますなぁ(・ｗ・。)

条件的にこれ以上は無さそうならば、

Add_Time、Add_Day
Update_Time、Update_Day

の項目を用意し、Addは、新規追加日。
Updateは、ともかくレコードの何かしらを更新した日。
にそれぞれデータ更新をかます。（まぁ、Addは一回のみですが。

で、やはり、PHP側で、Update日を見て、プログラム制御をするのが無難かと。

（と。いうか、別に、Addはいらないんですけどね。ただのデータ管理項目として追加するだけなので。

現状の疑問は「update_time」という項目を作るのはいいんですけど、何に使うんですか？
ですかね。

他の方の回答についている通り、他の項目もつ必要ありますか？が妥当なとこなんですよね。

あなたが実現したいという

>>同一のレコードが例えば半年後あるいは一年後には再び、新着レコードとなる場合が多々あるということです

コレ。
同一レコードのupdate_timeを、半年後に書き換えて、PHP側が「２週間以内のupdate_timeのレコードを新着記事として表示する」で組んでおけばいいわけなので。

現状、update_timeの項目と、estate_new_flagの項目の役割が、「重複できる」状態ですね。

>>そして新着期間の2週間目に、任意のクライアントPCからその情報が閲覧できるURLにアクセスした際に、
>>そのレコードのupdate_timeを参照して、２週刊前ならestate_new_flagを2へとupdateする、そうでなければスルー
>>という処理を行う、APIを作って叩かせるといった具合です。

んーここでもそう書いてますよね。
update_timeの役割とestate_new_flagの役割が大差ないです。

PHP側で、２週間経過してたらNewの表示を消す。
の方が、よっぽどつくりが単純＆工数が掛からずできる。といったところですね。

後は、「クライアントからアクセス時に、特定の処理を実行させて。。。」
って内容ですが、何かしらのバッチ処理を流させるというとこですかね？

これもあまりオススメはしません。

。。。正直、やったことはありますが、管理が面倒な上に、「アクセスしてきた際」という、不確定な要素を処理の中に組み込むことはオススメできません。。。そのため、今も、おいらが管理してるシステムは、たまに面倒になってます（笑

どうしてもフラグを別に持ちたくて、どうしてもバッチでフラグのチェック処理をしたければ、毎日定時にサーバ側に実行権限持たせて、やらせておいたほうがいいかと。（夜中の２時。とかに。

でも、「データの書き換え」は、極力行わないほうがいいですよ。というのが、おいらからの意見。
（書き換え場所が少なければ少ないほど、もしもの際に、追いかけやすいし、無駄なところを疑わなくて済むし。

ましてや、データは、自分のもの。じゃなく、客が使い始めりゃ客のもの。だったりしますからね。
極力、客のデータは書き換えないほうがよい。と考えてます。
（フラグの書き換えなだけだから、書き換えってほどじゃないじゃん。とか、update_timeの書き換えだって、書き換えじゃないの？とかって反論はあるかもしれませんが、書き換えのタイミング次第です。フラグの方は、バッチでシステム側で勝手に。update_timeの方は、誰か。。。利用者かシステム管理者が、画面上で「更新」ボタンを押した際のタイミングという点で、おっかけ安さが変わります。

さらに余計な事を考えるとしたら。。。

・「２週間前」というのを、可変に出来るような機能をつける。
・「再び新着のレコードとして扱わない」けど、レコード内容を更新した際にupdate_timeが更新されちゃ困るから、update_timeを更新しないようにする機能をつける。

とか。ですかね。。。

まぁ、いろいろとそれましたが、まとめると
update_timeも、estate_new_flagも、どっち使っても、PHP側で同じような感じになる処理は組めそうだから、それだったら、余計に手間をかけるであろう、estate_new_flagを使った方法は考えなくてもいいんじゃない？
といったところです。

回答No.2

agunuz

テーブルに列「update_time」以外にわざわざフラグの列を持つ必要があるのでしょうか？

SQL文でも経過日数を計算して新着かどうか（2週間以内か）のフラグを返すことは出来ますし、読んだ後でphpで計算してもいいならもっと簡単に書けると思いますが・・・

補足

update_time以外にフラグをもつ理由としては
同一のレコードが例えば半年後あるいは一年後には再び、新着レコードとなる場合が多々あるということです。

そして、要は管理画面から、対象のレコードを再び新着のレコードとして扱う必要があるため、estate_new_flagという列を考えております。

回答No.1

bm_hiro

やっぱり現状の仕様のものだと、cronで一日一回フラグ倒すアップデート処理するのがベターかなーと思います。

補足

左様ですか。
アプリケーション側でうまくやれるといいのですが
あまり、ロジックが増えると後のメンテがって考えると、
cronとかの方が管理はしやすいかなーとは思ってます。
幸い、運用するサーバはさくらのマネージド専用なのでcronやsshログインは可能です。