私のサイトでは、毎月の有料サブスクリプション アクセスを提供し、テーブルをセットアップする最善の方法を考えようとしていました。プレミアム サービスへのアップグレードを希望する場合、ユーザーはペイパルによる支払いを選択できます。ユーザーがサービスを中止することを選択した場合、アカウントは制限付きの無料アクセス バージョンに制限されると思います。
これをユーザーの詳細として単一のテーブルに維持できると考えています。
USERS
ID| NAME| MEMBERSHIP_TYPE| LAST_PAYMENT_DATE| ACTIVE_TILL| TRANSACTION_ID
それを2つの異なるテーブルに分ける必要がありますか
USERS
ID| NAME
MEMBERSHIPS
USER_ID|MEMBERSHIP_TYPE|LAST_PAYMENT_DATE|ACTIVE_TILL|TRANSACTION_ID
そして、支払いの履歴を 3 番目のテーブルに保存します。ここでは定期請求を使用します。
更新の履歴を表示できるようにするため、ユーザー リストから支払いトランザクションを分離する必要があります。支払い、払い戻しのリクエスト、再支払い、メンバーシップの期限切れ、更新などを行うユーザーがいる場合があります。このアクティビティの履歴を保持するトランザクション テーブルを維持しないと、顧客サービスや会計の問題を解決できなくなる可能性があります。
有料メンバーシップが 1 種類しかないと仮定し (これは将来的に安全な仮定ではない可能性があります)、ストアド プロシージャやトリガーを使用してトランザクション ラッパー内のデータを同期するなど、適切な手続き制御を配置すると仮定すると、メンバーシップ タイプを非正規化し、 USERS テーブルの日付まで有効です。このタイプの冗長性は、運用パフォーマンスに役立つ可能性がありますが、冗長データが同期しなくなると、非常に危険になる可能性もあります。USERS で非正規化フィールドを使用する前に、冗長性なしで試してみて、実際のパフォーマンスの問題があるかどうかを確認することをお勧めします。