4

私が関心を持っているユーザーは、「未確認」または「確認済み」のいずれかです。後者はフルアクセスを取得することを意味し、前者はモデレーターからの承認を待っていることを意味します。この構造を考慮してデータベースを設計する方法がわかりません。

私が持っていた1つの考えは、unconfirmedUserに追加のフィールド（「emailConfirmed」や「confirmationCode」など）があることを除いて、非常によく似た2つの異なるテーブルconfirmedUserとunconfirmedUserを持つことでした。ユーザーが受け入れられたときにすべての情報をコピーする必要があるため、これは少し実用的ではありません（ただし、それほど悪くはないと思いますが、大量のトラフィックは予想されません）。

これを想像した2番目の方法は、実際にすべてのユーザーを同じテーブルに配置し、必要に応じて追加の「未確認」データを含むテーブルへのキーを用意することです（おそらく、ユーザーテーブルに「確認済み」フラグを追加します）。

各アプローチの長所と短所は何ですか？データベースを設計するためのより良い方法はおそらくありますか？

4

4 に答える 4

5

最初のアプローチは、2 つのテーブルに対してすべてのクエリを作成する必要があることを意味します。悪い（tm）。2番目のオプションは間違いなく優れています。そうすれば、特定のアクセスに必要な単純なwhere confirmed = True(または False) を追加できます。

実際に考えられるのは、確認済みのデータ (ユーザーではなく、データのみ) が同じテーブルに格納されているかどうかです。おそらく、すべての確認データを別のテーブルに入れる方がクリーンで正規化されているため、left join confirmation on confirmation.userid = users.id where users.id is not null (または同様の、または内部結合、またはサーバー側スクリプトですべてを取得 + フィルターなどで)確認済みのユーザーのみを取得できます。確認メール、日付などの追加データはここに保存できます。

于 2012-08-23T16:32:53.203 に答える
3

論理的には、これは継承です (別名、カテゴリ、サブクラス化、サブタイプ、汎化階層など)。

物理的には、ここ、ここ、ここ、そしておそらくSOの他の多くの場所で言及されているように、継承は3つの方法で実装できます。

この特定のケースでは、すべてのタイプを同じテーブルに配置する戦略が最も適切と思われます1。これは、階層が単純で新しいサブクラスを獲得する可能性が低く、サブクラスの違いがわずかなフィールドであり、親レベルのキーを維持する必要があるためです (つまり、未確認のユーザーと確認済みのユーザーは重複するキーを持つべきではありません)。

1つまり、質問で言及されている「2 番目の方法」です。確認データも同じテーブルに入れるかどうかは、必要なカーディナリティに依存します。つまり、そこに 1:N の関係がありますか?

于 2012-08-23T19:02:03.290 に答える
3

個人的に私はあなたの2番目のオプションに行きます.ブール型の確認済み/保留中の列を持つ1つのユーザーテーブル。あるテーブルから別の同じテーブルにデータをコピーすることは実際的ではありません。

その後、グループを作成して各グループに特定のアクセス権を付与し、必要に応じて各ユーザーを特定のグループに割り当てることができます。

于 2012-08-23T16:37:11.987 に答える
1

これを行う最善の方法は、外部キーとしてステータス ID を持つユーザー用のテーブルを用意することです。ステータス テーブルには、さまざまな種類の確認と、さまざまな組み合わせがすべて含まれます。私の意見では、正規化とプログラミングのニーズに合わせてデータベースを構築するには、これが最善の方法です。

ステータステーブルは次のようになります

StatusID | Description
=============================================
1        | confirmed
2        | unconfirmed
3        | CC confirmed
4        | CC unconfirmed
5        | acct confirmed CC unconfirmed
6        | all confirmed

ユーザーテーブル

userID | StatusID
=================
456    |    1
457    |    2
458    |    2
459    |    1

確認コードが必要な場合は、ユーザー テーブル内に保存できます。使用後に変更するようにプログラムして、パスワードなどをリセットする必要がある場合に同じフィールドを使用できるようにします。

多分私はあまりにも多くを仮定していますか？

于 2012-08-23T16:31:42.207 に答える