データベーススキーマの設計：未確認の招待についてはどうすればよいですか？

Question

この問題に対処する方法がよくわかりません：

招待のみの登録システムを持つWebアプリケーションを作成しています。管理者ユーザーがユーザーに招待メールを送信し、ユーザーがリンクをクリックして、メールアドレスにリンクされたアカウントを作成できるページに移動します。

最初のアイデアは、 users テーブルに verified 列に false の行を挿入することでした。問題は、ユーザー名とパスワードが必須フィールドであり、ユーザー名が一意である必要があることです。そのため、空の行を挿入して後で記入することはできません。

招待状用に別のテーブルを作成する必要がありますか？このタイプのシナリオにアプローチする最良の方法は何ですか？

更新：管理者は、名、姓、電子メールアドレス、およびユーザーロール（権限）を入力します。したがって、これらすべてを招待テーブルに保存する必要があります。メールの再送信が必要になった場合、送信した日付を保存し、その値を更新することもできます。

Answer 1

はい、招待状を管理するために別のテーブルを作成します。

招待が受け入れられたら、いくつかの選択肢があります。最初に、追跡または「家系図」のいずれかのために、元の招待への関連付けを維持する必要があるかどうかを決定します。またはその他の歴史的な目的。

次に、もしそうなら、それをどうするかを決める必要があります。招待を削除し、ユーザーレコードに関連する情報を保存しますか？招待記録を保持し、外部キーを設定しますか

作成するシステムの詳細を知っていれば、さらに微調整したアドバイスを提供できるかもしれません。

Answer 2

招待状が紛失したり、偶然に削除されたり、その他のさまざまな理由で使用できないため再送信する必要があるシナリオを考慮する必要があります。

また、招待は登録とは別のエンティティです。別のテーブルを作成して招待を追跡し、誰がどの招待から登録したかを確認する必要があると思います

Answer 3

招待用に別のテーブルをお勧めします。あなたの招待は基本的に誰かが登録することを許可するトークンであることは私にはかなり明らかなようです。

Answer 4

別のテーブルが最も理にかなっています。これにより、ユーザーテーブルのデータの整合性を維持でき、より読みやすいデータモデルが提供されます。 「招待表に招待を入れる」と言う方が簡単です。 ＆quot;招待状はユーザーテーブルに送られますが、検証済みの列はfalseに設定されています＆quot;。

Answer 5

これを見るためのいくつかの方法。評価段階が終了するとどうなるかを別のテーブルを作成する別のルートに移動する場合、それらの評価ユーザーを実際のユーザーテーブルにコピーする必要がありますか？ユーザー名は、ユーザーテーブルへのエントリを処理するようにプログラムした特別に細工されたGUIDにデフォルト設定できます。