毎月 (または毎週) の定額の定期的な請求を伴うアプリケーションを作成しています。これは、サブスクリプションがキャンセルされるまで続く可能性があります。顧客は、複数の期間を前払いすることができます。彼はサブスクリプションをキャンセルし、一定の未払い期間後に戻ってくることができます。生理予定日を過ぎたことを知らせるシステムが必要です。
だから私はデータベースの設計方法に頭を悩ませています (データベースの問題ではなく、プログラミングの問題かもしれません)。
この種のアプリケーションに来た人はいますか? どのようなアプローチが取られましたか？
デザインを巧みに使いすぎて、考えすぎているのではないかと思います。ビジネス上の問題について考えると、各支払い間隔は実質的に請求書です。請求書テーブルを作成し、スケジュールされたジョブが各アカウントの周期性とその間隔中にアクティブであるかどうかに基づいて、特定の間隔で請求書を挿入するようにしないでください。
実際の請求書の行を持つことで、顧客からの支払いを求めるときに参照できる InvoiceID を取得し、請求ごとに個別に支払いステータスを追跡できます。
時にはシンプルイズベスト。
あなたはそれを複雑にしすぎていると思います。
テーブルユーザーを作成します。
pk id_user
nm_user
fl_status (active, canceled, pendent, etc)
1人のユーザーから多数のサブスクリプションへのテーブルサブスクリプションを作成します。
pk id_subscription
fk id_user
fl_type (maybe there are different subscriptions, with different prices)
dt_in
dt_out
多くの支払いに対する1つのサブスクリプションのテーブル支払いを作成します。
pk id_payment
fk id_subscription
fl_type (card, payment order, something else)
fl_status (generated, sent, confirmed, canceled because of subscription canceled, canceled because of something else, etc)
dt_generated
dt_sent
dt_confirmed
dt_canceled
[I think you will need another fields to follow and confirm the payment, but it depends of your payment model)
次に、特定の時間に毎日実行されるロボットをいくつか作成する必要があります。
すべてのアクティブなクライアントと各クライアントの最後の支払いを取得すると、最後に確認された支払いが実際の日付と比較してx日を超えて行われた場合に、新しい支払いを生成する必要があるかどうかがわかります（前払いか後払いかによって異なります） 、など）。はいの場合、新しい支払い注文を生成しました。
ロボットは、注文が記載された電子メールまたは何かを送信します（そしてフラグを立てます）。
別のロボットが、支払いモデルを使用して支払いを確認します。
もちろん、モデルを非常にうまく定義する必要があります。支払いがないためにキャンセルされるか、裁判官に送られるまで、各ユーザーステータスにはロボットが物事を続ける必要があるからです。やるべきことはたくさんありますが、大したことはありません。
ps：データベースが存続するより複雑なシステムになると、必要なすべての情報が得られ、すべての注文のログがあり、日付とステータスがあるため、それぞれに何が起こったのかがわかります。毎月、期日がいくつになるか、1日後、2日後などにいくつ支払うかを見積もることができます。