あなたのテーブルスキーマを知らなくても、何が最善であろうと言うのは少し難しいです。多くのユーザーがそのポーリングを実行する場合は、クライアントでフィルタリングを行うことをお勧めします。つまり、クエリから取得した各オープンジョブを追跡し、そのジョブに関連付けられたポーリング時間が5分未満の場合はクエリからフィルタリングします。そのジョブに関連付けられているポーリング時間が5分を超えると、もう一度それを要求します。
たとえば、サーバーにクエリを実行してジョブ1,2および3を開いた場合、それぞれに時間値を関連付けます(同じになります)。
照会次回のサーバ(10秒後にこの場合)あなたは5分未満古いこれらのジョブをフィルタリングしてください:
select * from table
where status = 'open' and jobid not in (1, 2, 3)
5分に合格したら、あなたは削除する必要がありますnot in
句のジョブID。
この解決方法は、クライアントに作業を委ねるので、データベーススキーマを変更する必要はありません。
編集:
興味深いが、ジョブのオープン時間は、通常、1と8分の間、平均5分です。 - chris
アルゴリズムは依然として適用されます。適切なtimeout
を選択する必要があります。 1分を選択すると、クライアントは不要なデータをより頻繁に取得します(ただし、状態の変更が早くなることに注意してください)。 8分を選択すると、クライアントは不必要なデータを少なくすることになります(ただし、8分後には状態の変化を認識します)。ソフトウェア要件に基づいて適切なタイムアウトを選択する必要があります。これは、コンピューティングのすべてとしてのトレードオフです。
私の意見:モバイルアプリケーションです:10秒ごとに50kbをダウンロードしないでください。このアプリケーションは、レストランが「オープン」になったときに教えてくれますか?そうであれば、8分の遅れがあればOKです。しかし、ジョブが原子炉のセンサーである場合、1分の遅れが多く見えるかもしれません:)
'LastChangeTime'列を追加し、最後の要求後に更新されたジョブのみを照会することができます。テーブルからレコードを物理的に削除することに注意してください。クライアントはレコードが消えたことを決して見られないからです。 – DCoder