eコマースアプリケーションでのゲストユーザーの処理
私は現在eコマースアプリケーションを開発しており、「ゲストチェックアウト」機能を追加する最善の方法を見つけようとしています。この機能を追加するために私が取り組んでいる3つの主なモデルは、住所、ユーザー、および注文です。住所にはユーザーが必要で、注文には住所とユーザーの両方が必要です。
ゲストのチェックアウトでは、誰かにアカウントを強制的に作成させたくはありませんが、現在のスキーマでは機能しません。
私が今考えることができる唯一の2つのオプションは次のとおりです。
- ユーザーテーブルにゲストアカウントを作成すると、ゲストのチェックアウトごとに、それに関連付けられた新しい注文と住所が作成されます。
- ユーザーの住所と注文のFK制約をオプションにします。
誰かがこれを経験したことがあるか、より良いオプションを考えることができますか？
ありがとう
どちらのオプションも適切に機能しますが、次の不便があります。
- ゲストアカウントにはさまざまな動作が必要です。アプリケーションは、他のゲストのプライバシーを確保するために、ゲストユーザーが以前のアドレスを表示または変更できないようにする必要があります。
- 両方のオプションを使用すると、一部のゲストアドレスの複数のバリアントが蓄積されるため、長期間にわたってデータベースが不必要に膨張します。
- 両方のオプションを使用すると、アプリケーションロジックで履歴の問題も管理する必要があります。注文が発送されると、配送先住所が変更されなくなります。ユーザーはしばらく前に発送された注文を受け取りませんが、その後アカウントの住所を更新します）。これには、アドレスのバージョン管理ロジックが必要になります。
ただし、永続オブジェクトのライフサイクルを詳しく見てみると、別の選択肢が現れます。
- 実際には、2種類のアドレスがあります。
- 登録ユーザーが管理できる現在の優先アドレス（廃止されたアドレスの削除を含む）
- 注文に使用され、注文が発送された後はそのままにしておく必要がある配送先住所
- 登録ユーザーのみにアカウントと（推奨）アドレスを使用します。
- 登録されたユーザーアカウントに対して、オプションのFK制約付きの注文を使用する
- 注文に配送名と住所のフィールドを追加します（複数アイテムの注文がある場合はヘッダーに）：
- 未登録ユーザーの場合、注文で直接アドレスを管理します。
- 登録ユーザーの場合、選択したアドレスを注文にコピーします。
- 注文ステータスが「発送済み」になると、注文の住所フィールドを変更できなくなります
- 数年後に古い注文をクリーンアップしたい場合（またはGDPRのために削除する必要がある場合）は、それらを破棄するだけで、不要な組み込みのワンタイム配送先住所がすべて自動的に削除されます。優先配送先住所は、引き続き有効です。これらは、（原則として）アクティブなアカウントにリンクされたアクティブな住所です。