課金システムを構築しています。システムは、クライアントへの毎月の請求書を生成する必要があります。
私が今行っているのは、Forループを使用して、すべてのクライアントの以前の請求書を確認し、クライアントの請求書を生成する時期かどうかを判断することです。
データベースに膨大な数のクライアントが存在する場合、そうすることは非常に重いと思います。
請求書を生成する標準的な方法は何ですか？クライアントの次の請求日を記録するcronジョブを作成し、請求書を生成する時間になったときにのみ特定のクライアントをチェックすることは可能ですか？
どうもありがとう
あなたはデータベースについて言及しています。使ってみませんか？
「前の請求日」列にインデックスを付け、WHERE句を追加して、最後の請求書が1か月以上前に送信されたクライアントのみを返します。
請求書を生成する標準的な方法は何ですか？クライアントの次の請求日を記録するcronジョブを作成し、請求書を生成する時間になったときにのみ特定のクライアントをチェックすることは可能ですか？
標準的な方法はありません。しかし、このタスクは確かにバッチジョブの典型的な候補です。すべてのクライアントに同時に請求する場合は月末に実行するか、毎日実行し、いくつかの日付基準に基づいて請求可能なクライアントのみを選択します。クライアントごとに、必要なことを実行します。データのサイズによっては、JPAが適切でない場合があります（またはHibernateを検討StatelessSessionするか、忘れてしまう可能性があります）。
スケジューラーの部分については、Quartzのようなエンタープライズスケジューラーや、Control-M、Dollar-U、TNGWorkloadなどのさらに大きな専用ソリューションをよく目にしました。
クライアントごとに1つのジョブを作成しないことを強くお勧めします。これは実際には良い解決策ではありません（管理するのが大変、拡張できないなど）。
レオン、実際にそのような標準的な方法があるかどうかはわかりません。各企業文化は、プロセスが要件に合うように最適に実行される方法をある程度定義します。オンデマンド処理の両極端を実行するアプリと、バッチプロセスとして請求を実行するアプリがあります。一般に、両方に対応するインターフェイスを構築するのは良いことです。また、ある時点でサードパーティがWebサービスなどを介してAPIを要求する可能性を考慮する必要があるかもしれません（コスト削減のために、問題の会社は実際に請求書を「公開」するためにビューローサービスを使用する場合があります-私はこれを1日から知っています手の経験）。また、データベース構造はかなり堅牢で、プロセスのいずれかが失敗した場合などに備えて、十分なフォールバックポイントを備えている必要があります。
とにかく-ディベート...:)
ジム