.net 实体框架-一端不是主键的1对1关系

我想在实体框架数据模型中定义一种关系，这种关系是1对1的，一端是一个表的主键，另一端是另一个表的外键。例如：

table: aspnet_Users
w/ col: UserId guid Primary Key

使用与用户表的AspUserId列相关的aspnet_Users表的UserId属性：

table: User
w /col: UserId int Primary Key
w /col: AspUserId guid

CREATE TABLE [dbo].[User](
    [UserId] [int] IDENTITY(1,1) NOT NULL,
    [AspUserId] [uniqueidentifier] NOT NULL,
    [ModifiedDate] [datetime] NOT NULL,
    [CreatedDate] [datetime] NOT NULL,
CONSTRAINT [PK_User] PRIMARY KEY CLUSTERED 
(
    [UserId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF,     ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[User]  WITH CHECK ADD  CONSTRAINT [FK_User_aspnet_Users] FOREIGN     KEY([AspUserId])
REFERENCES [dbo].[aspnet_Users] ([UserId])
GO

ALTER TABLE [dbo].[User] CHECK CONSTRAINT [FK_User_aspnet_Users]
GO

当我尝试这样做时，我得到一个错误，因为AspUserId字段不是它的表的主键，所以无法工作：

错误21错误113:多重性在关系“FK\U User\U aspnet\U Users”中的角色“User”中无效。因为依赖角色属性不是键属性，所以依赖角色的多重性上限必须为*

---

外键需要映射到主键。否则，可能会出现以下记录：

aspnet_Users
UserId 
11111111
11111111
22222222

User
UserId AspUserId
1      11111111
2      11111111

这是没有意义的，并且打破了你的1-1基数

然而，也就是说（看看一个旧的会员数据库-恶心），

dbo.aspnet\u Users

上的

UserId

字段是一个主键

您确定您的外键在正确的表上吗？数据库中的

dbo.aspnet\u用户是否具有
UserId
的主键

此外，尽量不要映射成员表，这将是一个痛苦的世界。成员模式中的关系非常复杂

只需映射您自己的用户表。将FK用于数据库端工作（审计、存储过程、触发器等）是很好的

但是从模型方面来说，您应该通过EF与您的用户实体交互，并通过成员资格提供者API与您的aspnet_用户（成员资格）实体交互

如果您需要在代码中“将它们缝合在一起”（通常情况下），请将其封装在服务后面。
响应用户表中的海报：

table: User
w /col: UserId int Primary Key
w /col: AspUserId guid

CREATE TABLE [dbo].[User](
    [UserId] [int] IDENTITY(1,1) NOT NULL,
    [AspUserId] [uniqueidentifier] NOT NULL,
    [ModifiedDate] [datetime] NOT NULL,
    [CreatedDate] [datetime] NOT NULL,
CONSTRAINT [PK_User] PRIMARY KEY CLUSTERED 
(
    [UserId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF,     ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[User]  WITH CHECK ADD  CONSTRAINT [FK_User_aspnet_Users] FOREIGN     KEY([AspUserId])
REFERENCES [dbo].[aspnet_Users] ([UserId])
GO

ALTER TABLE [dbo].[User] CHECK CONSTRAINT [FK_User_aspnet_Users]
GO

是的，实际上aspnet_Users上的UserId字段是一个主键，我似乎遇到的问题是AspNetUserId字段，它不是表：User的主键。如果我可以回去重新做一遍，我想我可能已经将用户表的PK设置为guid，并与aspnet_Users表的UserId字段匹配，我不确定这是否值得更改，但我认为这将解决我的1对1 EF模型关系问题。我想我希望有其他的解决办法。@BrooklynDev-
AspNetUserId
字段不需要是用户表的PK。这是外键。外键映射到另一个表上的PK。您确定是在
User
表上而不是在
aspnet\u Users
表上创建了FK吗？您能为
用户
表显示CREATE TABLE语句吗？是的，我确定AspUserId是一个FK，我的问题似乎是EF希望外键也成为其表的主键，如果它允许我定义与它的1对1关系：创建表添加到下面：啊，好吧-也许它确实需要
AspUserId
作为
User
上的主键。尝试删除
UserId
列并将
AspUserId
设置为PK/FK。正如我所说的，如果您甚至能够通过那里的成员表验证您的模型，我会感到惊讶。我仍然建议使用提供者API。但这是你的决定。