0

ユーザーがイベントに登録できるフリーランスの Web アプリケーションがあります。私のデータベースには、t_users.user_id 列にリンクされた外部キー制約を持つ列 t_events_applications.user_id を持つ t_events_applicants テーブルがあります。したがって、これは、Web アプリケーションに登録したユーザーのみが Web アプリケーションのイベントに登録できることを意味します。

私のクライアントは、未登録ユーザー (私の t_user テーブルにエントリを持たないユーザー) がイベントに登録できるようにしたいと考えています。これらの未登録ユーザーは、名前と電子メール アドレスを提供するだけで、イベントに登録できます。

name 列と email 列を含む t_temporary_user テーブルを作成してから、t_events_applicants.user_id fk 制約を削除する必要がありますか? または、未登録ユーザーを t_user テーブルに追加してから、タイプが「登録済み」または「未登録」の t_user.type という列を追加する必要がありますか?

どのアプローチを使用するかをどのように決定しますか?

多くの場合、どちらのアプローチにも躊躇します。「後で、一時ユーザーが完全に登録されたユーザーになることを許可されたらどうなるでしょうか。その場合は、t_user テーブルのみを使用する必要があるかもしれません。しかし、多くの一時ユーザーを保存することにも満足できません。 t_user で」

4

3 に答える 3

2

それが本来の役割ではないでしょうか。

users テーブルを作成し、いくつかのロール (users_roles に対する多対多数) を与えます。
ロール テーブルに、イベントへの登録を許可するロールと、Web サイトの残りの部分に対するさまざまな権限のロールを追加します。
そうすれば、イベントのみのユーザーを本格的なユーザーに昇格させる (正しいロールを追加する) ことが簡単になり、後で他のものを追加することができます (他のイベント、特別なサブスクリプションなど)。
とにかく、すでにそのようなシステムを導入している可能性が高い..

于 2010-03-09T12:48:16.200 に答える
0

私はあなたの 2 番目のアプローチを使用します。それらを同じテーブルに追加しますが、[タイプ] 列を使用します。2 つのユーザー テーブルを作成する場合、ユーザーを見つけるために常に両方をチェックする必要があります。単純にしてください。彼らはユーザーであり、タイプが異なるだけです。

ユーザー (またはその他の) テーブルに CreateDate または LastLogin の日付がある場合は、一定時間後に一時ユーザーを削除できます。

于 2010-03-09T12:41:56.720 に答える
0

新しいシステム要件を考えると、登録ユーザーと非登録ユーザーの区別が間違っているようです。それらをすべて1つのテーブルにまとめます。サイト登録情報を別のテーブルに保持します。ユーザーがサイト登録テーブルへの JOIN で登録されているかどうかを判断できるため、結合されたテーブルに type 列さえ必要ありません。

于 2010-03-09T12:53:38.300 に答える