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 to Users，我将保持一致性并Users在数据库中的其他关系中用作父表。

但是，如果它是真正的一对一而不是一对零或一对一的关系，那也没关系。

另一个考虑因素是任何应用程序如何访问此数据库中的数据。应用程序是否使用 OR/M 之类的实体框架，它知道 FK 关系？如果是这样，请考虑使用具有基于子表的查询最常访问的列的表。例如，一个应用程序可能会到处显示Profiles.LastName并且Profiles.FirstName很少从Users表中读取任何内容。Profiles在这种情况下，您将通过在表外建立关系为您的数据库节省一些 I/O，并为您的开发人员节省一些击键。

于 2013-02-25T23:39:24.507 回答