C# 首先通过代码处理多个1对1关联的问题？

我使用代码优先的方法来创建数据库。在这里，我尝试使用

共享主键

方法实现1对1关系：

public partial class AccountHolder
{
    public int AccountHolderId { get; set; }

    public virtual PersonalDetail Detail { get; set; }
}

//Added later 
public partial class Nominee
{
    public int NomineeId { get; set; }

    public virtual PersonalDetail Detail { get; set; }
}

public partial class PersonalDetail
{
    public int PersonalDetailId { get; set; }

    ... 
}

我的fluent Api代码：

        modelBuilder.Entity<AccountHolder>().HasOptional(p => p.Detail)
                                            .WithRequired()
                                            .WillCascadeOnDelete();
        //Added later
        modelBuilder.Entity<Nominee>().HasOptional(p => p.Detail)
                                      .WithRequired()
                                      .WillCascadeOnDelete();

modelBuilder.Entity（）.has可选（p=>p.Detail）
.WithRequired（）
.WillCascadeOnDelete（）；
//后来添加
modelBuilder.Entity（）.has可选（p=>p.Detail）
.WithRequired（）
.WillCascadeOnDelete（）；

最初，我只有两个表

AccountHolder

和

PersonalDetails

，共享主键方法在这两个表上运行良好。但是现在，当我添加

提名人

表时，问题出现了，该表与

个人详细信息

也有1对1的关系。添加新表后，当我运行代码首次迁移的更新数据库命令时，异常发生：

操作失败，因为表“PersonalDetails”上已存在名为“IX_PersonalDetailId”的索引或统计信息

谁能告诉我问题出在哪里，我该如何解决这个问题

编辑：

---

我在这里分享我对这个问题的研究，如果我错了，请纠正我。可能发生这种异常是因为在共享主键方法中，依赖表的PK也是主表的FK。因此，在这种情况下，有两个主要表，即

账户持有人

和

被提名人

，用于1个从属表，即

个人详细信息

。因此，当Entity framework尝试创建两个同名的FK时，会出现上述异常。

我想对我的评论进行扩展

---

即使解决了命名问题，也不能让一列成为两个表的外键

假设您的AccountHolder表有以下记录

Id
----
1
2
3

Id
----
3
4
5

您的提名人表有以下记录

Id
----
1
2
3

Id
----
3
4
5

假设您想使用

DetailId=3

将记录插入PersonalDetail。这与提名人3或账户持有人3相符吗

---

此外，如果您尝试使用

DetailId=2

插入PersonalDetail，您将收到FK冲突，因为没有被提名人2。如果您要插入

DetailId=4

，则没有AccountHolder 4，因此您将获得FK冲突。

您必须在

PersonalDetail

属性中使用基类（

AccountHolder

和从中派生的

Nameizer

）。我想这可以和TPH继承一起工作。你的迁移是什么样子的？我刚刚读了你的编辑，是的。PersonalDetail应为主体表，AccountHolder和Submited应为从属表，但PersonalDetail中的两个同名FK（1个为AccountHolder，1个为Submited）之间的当前冲突有何解决办法？即使您解决了命名问题，不能将一列作为两个表的外键。感谢您的解释，现在我很清楚我在这张便笺中做错了什么，简单地切换关系并将PersonalDetail设置为principal表就可以解决这个问题。如果我正确理解您的评论，那么

principal总是可以在没有依赖关系的情况下存在，因此我认为只有PersonalDetail没有所有者（帐户持有人或被提名人）没有道理，不是吗？从数据库的角度来看，这是真的。然而，您可以通过业务逻辑来控制它，所以我可能不会太担心它。