1

UsersWeb サイトの登録ユーザーを表すというテーブルがあるとします。またAccountActivation、新しいユーザーの電子メールを確認するためにランダムに生成された文字列を格納するテーブルもあります。

AccountActivationテーブルには、テーブルUserIdの主キーでもある列がありUsersます。ActivationCodeコードを格納する列もあります。どちらの列でも、AccountActivationテーブル内の行を一意に識別できます。

したがって、アクティベーション コード列を主キーとして選択すると、異なる主キーを持つ 2 つの 1 対 1 のテーブルができてしまいます。1 対 1 の関係では、2 つのテーブルに同じ主キーが必要だと思いましたか?

4

4 に答える 4

1

1 対 1 の関係を持つために、2 つのテーブルの主キーと同じ列を持っている必要はありません。
テーブルの任意の列を主キーとして使用できAccountActivationます。

UserIdテーブルへの外部キーは、AccountActivationテーブルの主キーUsersです。AccountActivationそのため、テーブルの主キーであるかどうかに関係なく、この列を使用してテーブルからユーザーのアクティベーション コードを一意に識別できるはずです(ただし、一意である必要があり、そうなることを願っています)。

于 2012-06-25T16:52:43.480 に答える
1

ActivationCodePK として選択した場合、なぜ1 対 1 の関係が 2 つあるのですか?

そこにある唯一の関係は

AccountActivation.UserId -> Users.UserId

または、他に何を突然持っていると思いますか？

あなたが提案したことを実行すると、テーブルのUsersPKがオンにUserIdなり、テーブルのAccountActivationPKがオンになりますActivationCode-まったく問題はなく、このようにしない理由はありません。

の PK にどの列 (UserIdまたはActivationCode) を選択してAccountActivationも問題ありません。これは、 と の間の FK 関係に影響を与えたり妨害したりせずAccountActivation、Userいかなる種類の追加の 1 対 1 の関係も追加しません .....

ActivationCodeの PK を選択した場合、私が行う追加の手順は、2 つのテーブルを結合するクエリで最大のパフォーマンスが得られるようにAccountActivation非クラスター化インデックスを作成することだけです。UserId

于 2012-06-23T11:31:22.943 に答える
1

1 つしかない場合はActivationCode、共有できますUserId。ただし、これは、ユーザーがキーを再生成したときに、古い行を更新するか削除する必要があることを意味します。

しかし、なぜそのようなデータを保存する必要があるのでしょうか? また、アカウント アクティベーション コードを、User.

私の提案を説明するために：

Users table has two columns UserId CreationDate

その場合、トークンはUserId + CreationDate(例) のようになります。データベースに余分なデータがなくても、生成してチェックすることができます。これがお客様の要件に合わない可能性があることは承知しています。

于 2012-06-23T11:31:48.583 に答える
1

AccountActivation の UserId 列を、Users テーブルへの外部キーにします。

Users
=====

UserId primary key
Name
Address
etc...

AccountActivation 
=================

UserId primary key (foreign key to Users.UserId)
ActivationCode (unique constraint)

これで 1 対 1 の関係になりました

于 2012-06-23T11:32:49.610 に答える