私はあなたがそれを複雑にしていると思います。
テーブルのユーザーを作成します。
pk id_user
nm_user
fl_status (active, canceled, pendent, etc)
は、多くのサブスクリプションへの表サブスクリプション一人のユーザーを作成します。
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)
:
pk id_subscription
fk id_user
fl_type (maybe there are different subscriptions, with different prices)
dt_in
dt_out
を多くの支払いをテーブルの支払い1つのサブスクリプションを作成します。今では、いくつかの特定の時間に毎日実行するいくつかのロボットを構築する必要があります。
アクティブなクライアントとそれぞれの最終支払いを取得した場合、最後に確認された支払いが実際の日付と比較してx日以上経過した場合に新しい支払いを生成する必要があるかどうかを知ることができます前払い、後払いなど)。はいの場合は、新しい支払い注文を生成します。
ロボットが注文したメールや何かを送信します。
別のロボットがお支払いモデルを使用して支払いを確認します。
もちろん、各ユーザーのステータスには支払いがないためにキャンセルされるか、裁判官に送られるまで、ロボットが状況を維持する必要があるため、モデルを非常によく定義する必要があります。それは大変な仕事ですが、大きな問題はありません。
ps:より複雑なシステムになると、データベースは持続し、必要なすべての情報を得ることができます。すべての注文のログがあります。状態。あなたは、あなたが持っている予定日数、1日後、2日後に何人が支払うかを見積もり、月々に計算することができます。
私は支払いを請求書と支払いテーブルに分け、これはOKと思われる以外のより標準的なフィールド名( 'id'、 'subscription_id'など)を使用します。 Agile Toolkitは、さまざまなデータベース設計レイアウト(http:// agiletoolkit)を処理できます。org/learn/understand/model/add – romaninsh