php sql 翌月に変わったときに1回だけsqlを実行する方法

Question

前提・実現したいこと

![]

お世話になります。
phpやSQLを勉強中の初心者です。

まず、今月と来月の予約システムを作成しようとしています。
8時から22時までの２時間おき*31日分の予約可能枠数を入れており
予約が入ると枠数が１つ減り、0になると表示上ではバツが出るようにしています。
今月はテーブルreserv 来月はreserv2というふうに分けていたのですが、
月が変わった時にカレンダーの表示は変わっても、データ自体はそのままになってしまうので、それをなんとかしたい。というのがこの質問につながっています。

添付画像のように、今月と来月のテーブルがあり、
月が変わった時に　(5月なら6月に　6月なら7月)
来月だったデータを今月にコピー　来月のデータを新しい月用に更新（リセット)
できる様にします。

実現したいことは
この一連の操作を月が切り替わったら、1回だけ実行したい　ということです。

date()で　=06-01-00:00 という指定をすれば、00:00の瞬間しか実行されないでしょうし
かといって、　>=06-01-00:00 では、00:00以降なら何回でも実行されることになるかと思います。

何か方法ありますでしょうか？

該当のソースコード

この操作を月が変わった時に1回だけ実行したい
DELETE FROM `reserv`; //今月のテーブルを空に
INSERT INTO reserv SELECT * FROM reserv2;　//空になったところに来月のデータをコピー
UPDATE `reserv2` SET `count`=5　//来月のデータは新しい月用にリセット

試したこと

日時の取得について調べましたが　それらしい記述に辿り着けず

Answer 1

そもそも、その処理を起動するのは誰？
という事で、「スケジューラーで、毎月１日に実行する。」のが良いかと思います。

Comments

[mikage126]

恐れ入ります。
処理の起動は翌月に変わったときに初めて訪れた人、となるのかなと考えます。
スケジューラーで毎月1日に実行する　とはどのようにするのでしょうか

[sazi]

誰も訪れなかったらどうしますか。
なので、定周期にその月分のデータをコピーした方が良いと思います。

スケジューラーは殆どのOSに含まれている機能ですので、利用するOSに合わせて調べてみてください。
WINDOWSなら「タスクスケジューラ」です。

Answer 2

質問する内容を間違えてる。
「一度だけ実行」を解決しても何も解決しない。

質問よりももっと前の段階のそもそもやりたいことは何かの情報が必要。
やりたいことに対するテーブル設計を間違えてるから質問のような無駄な処理が必要になる。
今月がreserv、来月がreserv2って普通に考えればおかしい。
削除してコピーするような変なことをしなくていい設計にするのが先にやるべきこと。

Comments

[mikage126]

恐れ入ります。
まず、今月と来月の予約システムを作成しようとしています。
8時から22時までの２時間おき*31日分の予約可能枠数を入れており
予約が入ると枠数が１つ減り、0になると表示上ではバツが出るようにしています。
今月はテーブルreserv 来月はreserv2というふうに分けていたのですが、
月が変わった時にカレンダーの表示は変わっても、データ自体はそのままという状態になってしまうので、それをなんとかしたい。というのがこの質問につながっています。
そもそもの設計が間違っているとのことで、どの様にすれば月が変わった時の対応が可能になるのでしょうか？ご教授いただけますと幸いです。

Answer 3

よくある方法としては

1. CLIで動くアプリケーションとして作成する(php cli アプリケーションあたりで検索してみて下さい)
2. cronやタスクスケジューラーといった、OSが提供する機能を使って1のアプリケーションを定時（この場合だと毎月1日の0時に実行）に実行する

といった形かなと思います。
php cron 自動実行あたりをキーワードにして調べてみるとイメージがつきやすいかと思います。

レンタルサーバーなどでcronやCLIが使えない場合は、

1. 定時タスク用のアプリケーションを作る（複雑で長いパスにし、認証をかけるなどして一般の人が叩けないようにする）
2. 1で設定したURLを定時に叩くような外部サービスを利用する（使ったことは無いですがcron-job.orgなどのサービスがあるので、要件に合わせて選定）

という方法もあります。

最初に訪れたユーザーに実行させるのは色んな意味でお勧めできません。（そういう実装のアプリケーションが存在しない訳ではありませんが）

ただ、DB設計としてそのような作業が必要なケースというのはそれなりに限られるので、今回のケースがcron等で対応するのが適切かどうかはわかりません。（余程深刻な事情がある場合以外は不適切だと思います）

そのため、先に定時での洗い替えが必要にならないDB設計を検討するのが良いかもしれません。

Answer 4

皆様、たくさんのご回答ありがとうございました。
意見を聞いたり、自分で色々考えた結果、データベース設計を見直してみました。

いちいち２つのテーブルを洗い直すのではなく
テーブル名に年と月をふっておいて、
fromを呼び出す際に　$now_year $now_month、今年今月
あるいは　$now_year $next_moth、今年来月
とすることにしました。

月が変わっても、新しいテーブルをどんどん作っていけば問題なくいきそうです。

Comments

[AbeTakashi]

解決したということでこのコメントは蛇足なのかもしれませんが、テーブルを分けることによるデメリットも考慮されていますでしょうか？　たとえば予約状況を年ごとに集計するとか、これまでの通算の予約数を出そうとするとかをする場合は逆にちょっと面倒なことになります。予約の新機能を追加する際に月をまたぐような処理が必要になった場合も色々不都合が多そうです。また、テーブル数がいずれ膨大になるとそれらの管理も面倒になったりします。なんとなくですが、長い目で見てもこの方法がベストな感じは受けませんでした。個々の事情もあると思うので、あくまで「感じ」ではありますが。

[tanat]

毎月新しいテーブルを作ると言うのは一般的には良くない設計です。

予約テーブルに年月日のフィールドを持たせて、現在年月日との比較で今月なのか翌月なのか判断する
で解決しませんか?

[mikage126]

恐れ入ります。
あくまでこの場のテーブルはその月その日その時間の予約の残り枠数を管理していくものと考えておりまして、実際の予約状況は別のテーブルに更新していく形にと考えております。　集計の面では問題ないかと思うのですが...
膨大になったテーブルの管理は、現在から1年前のテーブルは削除する　という
仕組みをとればそこも問題ではないのかなと思うのですがどうなんでしょうか

[tanat]

> 膨大になったテーブルの管理は、現在から1年前のテーブルは削除する　という
> 仕組みをとればそこも問題ではないのかなと思うのですがどうなんでしょうか

困るか困らないかは要件次第ですが、一般的なRDBMSの設計としては「奇異」や「バッドノウハウ」に分類される類の設計になるかと思います。

結果として、将来的に発生する問題に対して一般的な手法が通用しなくなるのでお勧め出来ません

[tanat]

なので、入門書で構わないので一度RDBMSの設計を学習してからデータモデルの設計し直す事をお勧めします

[sazi]

一度正規化について目を通した方が、扱いやすいテーブルが設計できると思います。
また、正規化されていないテーブルを参照しようとすると、SQLは結構な量を記述しなければならなくなります。