0

私はテーブルを持っていますUsers:

    [UserId] [int] IDENTITY(1,1) NOT NULL,
    [UserName] [nvarchar](20) NOT NULL,
    [Email] [nvarchar](100) NOT NULL,
    [Password] [nvarchar](128) NOT NULL,
    [PasswordSalt] [nvarchar](128) NOT NULL,
    [Comments] [nvarchar](256) NULL,
    [CreatedDate] [datetime] NOT NULL,
    [LastModifiedDate] [datetime] NULL,
    [LastLoginDate] [datetime] NOT NULL,
    [LastLoginIp] [nvarchar](40) NULL,
    [IsActivated] [bit] NOT NULL,
    [IsLockedOut] [bit] NOT NULL,
    [LastLockedOutDate] [datetime] NOT NULL,
    [LastLockedOutReason] [nvarchar](256) NULL,
    [NewPasswordKey] [nvarchar](128) NULL,
    [NewPasswordRequested] [datetime] NULL,
    [NewEmail] [nvarchar](100) NULL,
    [NewEmailKey] [nvarchar](128) NULL,
    [NewEmailRequested] [datetime] NULL

このテーブルはと 1 対 1 の関係がありProfilesます:

    [UserId] [int] NOT NULL,
    [FirstName] [nvarchar](25) NULL,
    [LastName] [nvarchar](25) NULL,
    [Sex] [bit] NULL,
    [BirthDay] [smalldatetime] NULL,
    [MartialStatus] [int] NULL

データベース内の他のすべてのテーブルに接続userする必要があるため、次のことをお勧めします
。1) Users- から他のテーブルへの関係を作成しますか?
2) Profiles- から他のテーブルへのリレーションを作成しますか?

4

2 に答える 2

2

テーブル [Users] には Identity 値が含まれているため、[UserID] 値が発生する場所であるため、すべての外部キーをそこに戻して作成します。パフォーマンスの観点からは、[UserID] 列に設定された両方のテーブルにクラスター化インデックスがあると仮定すると、パフォーマンスへの影響はほとんどありません。

技術的には、[Users] テーブルには行ごとにより多くのデータを含めることができるため、インデックスはより多くのページにまたがる可能性があり、ルックアップでミリ秒の差が生じる可能性があると思いますが、[UserID を作成したテーブルに関連付ける方が理にかなっていると思います] と同様の名前が付けられています。とはいえ、実際にはどちらでもかまいません。

于 2013-02-25T23:17:54.063 に答える
0

の PKProfilesが の FKである場合、Users一貫性を維持しUsers、データベース全体の他の関係で親テーブルとして使用します。

ただし、それが真の 1 対 1 であって、1 対 0 または 1 の関係でない場合は問題ありません。

もう 1 つの考慮事項は、このデータベース内のデータがアプリケーションによってどのようにアクセスされるかです。アプリケーションは、FK 関係を認識する Entity Framework のような OR/M を使用していますか? その場合は、子テーブルに基づくクエリによって最も頻繁にアクセスされる列を持つテーブルを使用することを検討してください。たとえば、アプリケーションがあちこちに表示さProfiles.LastNameれ、テーブルProfiles.FirstNameから何も読み取ることはめったにない場合があります。Usersこの状況では、テーブルから関係を構築することで、データベースの I/O を節約し、開発者のキーストロークを節約できますProfiles

于 2013-02-25T23:39:24.507 に答える