EF Core+Sqlite中用单Address表为多表存储地址的最优方案

在Entity Framework Core结合Sqlite的开发场景中，我有一张存储地址数据的Address表，希望用它为多个不同的表（比如Client、Supplier、Shift）存储地址信息。目前仅实现了与Client表的关联，通过在Address类中添加ClientId和Client字段，但这种方式仅支持关联单个表。我考虑修改Address类，添加一个BaseModel类型的列表：

public List<BaseModel> AddressObjects { get; } = new List<BaseModel>();

理论上这样无需为每个需关联的表在Address类中新增字段，想请教实现该需求的最佳/规范做法是什么？

当前代码结构如下：

Address类 #

public partial class Address: BaseModel
{
    public int Id { get; set; }    

    [ObservableProperty]
    private string? _unitNum;

    [ObservableProperty]
    [NotifyDataErrorInfo]
    [Required(ErrorMessage = "Street Number is Required")]
    private string _streetNum;

    [ObservableProperty]
    [NotifyDataErrorInfo]
    [Required(ErrorMessage = "Street Name is Required")] 
    private string _streetName;

    [ObservableProperty]
    [NotifyDataErrorInfo]
    [Required(ErrorMessage = "Street Type is Required")]
    private string _streetType;

    [ObservableProperty]
    [NotifyDataErrorInfo]
    [Required(ErrorMessage = "Suburb is Required")]
    public string _suburb;

    [ObservableProperty]
    [NotifyDataErrorInfo]
    [Required(ErrorMessage = "City is Required")]
    private string _city;

    public int? ClientId { get; set; }
    public Client? Client { get; set; }
}

Client类 #

public partial class Client : Person
{
    public int Id {  get; set; }    

    public Address BusinessAddress { get; set; } = null;    
}

Supplier类 #

public partial class Supplier : Person
{
    public int Id {  get; set; }    

    public string SupplierType { get; set; }

    public Address ShopAddress { get; set; } = null;    
}

Shift类 #

public partial class Shift : BaseModel
{
   public int Id { get; set;}
   public Address ShiftLocation {get; set;}
}

Person类 #

public abstract partial class Person: BaseModel
{
    public int Id { get; set; }

    [ObservableProperty]
    [NotifyDataErrorInfo]
    [Required(ErrorMessage = "First Name is Required")]
    private string _firstName;

    [ObservableProperty]
    [NotifyDataErrorInfo]
    [Required(ErrorMessage = "Last Name is Required")]
    private string _lastName;
}

根据你的业务场景，推荐以下三种规范实现方式，各有适用场景：

方案1：多外键显式关联（最直接的常规方案） #

这是关系型数据库中处理一对多/一对一关联的标准做法，为每个需要绑定地址的实体在Address类中添加对应的外键和导航属性，同时配置明确的关系映射。

修改后的Address类

public partial class Address: BaseModel
{
    // 原有地址字段保持不变...

    // Client关联
    public int? ClientId { get; set; }
    public Client? Client { get; set; }

    // Supplier关联
    public int? SupplierId { get; set; }
    public Supplier? Supplier { get; set; }

    // Shift关联
    public int? ShiftId { get; set; }
    public Shift? Shift { get; set; }
}

在DbContext中配置关系（可选，EF Core通常能自动识别，但显式配置更清晰）

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    // Client与Address的一对一关系
    modelBuilder.Entity<Client>()
        .HasOne(c => c.BusinessAddress)
        .WithOne(a => a.Client)
        .HasForeignKey<Address>(a => a.ClientId)
        .OnDelete(DeleteBehavior.SetNull);

    // Supplier与Address的一对一关系
    modelBuilder.Entity<Supplier>()
        .HasOne(s => s.ShopAddress)
        .WithOne(a => a.Supplier)
        .HasForeignKey<Address>(a => a.SupplierId)
        .OnDelete(DeleteBehavior.SetNull);

    // Shift与Address的一对一关系
    modelBuilder.Entity<Shift>()
        .HasOne(s => s.ShiftLocation)
        .WithOne(a => a.Shift)
        .HasForeignKey<Address>(a => a.ShiftId)
        .OnDelete(DeleteBehavior.SetNull);
}

优点：

• 逻辑直观，代码可读性强，维护成本低
• EF Core原生支持，无需复杂配置
• 查询时关联明确，不会出现歧义

缺点：

• 每新增一个带地址的实体，需要在Address类中添加对应外键和导航属性
• 表中会存在多个可为空的外键字段

方案2：继承+分辨器（灵活扩展方案） #

利用EF Core的继承映射功能，创建一个抽象的地址所有者基类，让所有需要地址的实体继承该基类，通过单外键+分辨器字段区分不同所有者类型，避免频繁修改Address类。

步骤1：创建地址所有者基类并调整现有实体继承关系

// 新增抽象基类
public abstract class AddressOwner : BaseModel
{
    public int Id { get; set; }
}

// 调整现有实体继承
public abstract partial class Person : AddressOwner
{
    // 原有Person字段保持不变...
}

public partial class Client : Person
{
    // 原有Client字段保持不变...
    public Address BusinessAddress { get; set; } = null;    
}

public partial class Supplier : Person
{
    // 原有Supplier字段保持不变...
    public Address ShopAddress { get; set; } = null;    
}

public partial class Shift : AddressOwner
{
    // 原有Shift字段保持不变...
    public Address ShiftLocation { get; set; }
}

步骤2：修改Address类

public partial class Address: BaseModel
{
    // 原有地址字段保持不变...

    public int? AddressOwnerId { get; set; }
    public AddressOwner? AddressOwner { get; set; }
}

步骤3：在DbContext中配置继承与关联

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    // 配置AddressOwner的TPH（表每层次）映射，用分辨器区分子类
    modelBuilder.Entity<AddressOwner>()
        .HasDiscriminator<string>("OwnerType")
        .HasValue<Client>("Client")
        .HasValue<Supplier>("Supplier")
        .HasValue<Shift>("Shift");

    // 配置Address与AddressOwner的一对一关系
    modelBuilder.Entity<Address>()
        .HasOne(a => a.AddressOwner)
        .WithOne()
        .HasForeignKey<Address>(a => a.AddressOwnerId)
        .OnDelete(DeleteBehavior.SetNull);
}

优点：

• Address类无需频繁修改，新增带地址的实体只需继承AddressOwner
• 表结构简洁，仅需一个外键字段

缺点：

• 继承结构会增加代码复杂度，需梳理现有实体的继承层级
• 查询时需通过OfType<T>筛选特定类型的所有者，或进行类型转换

方案3：多对多关联+类型标记（地址共享场景） #

如果你的业务允许一个地址被多个实体共享（比如多个班次使用同一个地址），可以通过中间关联表实现，同时标记地址的使用类型和所有者类型。

步骤1：创建关联表实体

public class AddressLink : BaseModel
{
    public int AddressId { get; set; }
    public Address Address { get; set; }

    public int OwnerId { get; set; }
    public string OwnerType { get; set; } // 例如"Client"、"Supplier"、"Shift"
    public string AddressUsage { get; set; } // 例如"BusinessAddress"、"ShopAddress"、"ShiftLocation"
}

步骤2：修改Address类

public partial class Address: BaseModel
{
    // 原有地址字段保持不变...

    public List<AddressLink> AddressLinks { get; set; } = new List<AddressLink>();
}

步骤3：在DbContext中配置关联

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    // 设置复合主键
    modelBuilder.Entity<AddressLink>()
        .HasKey(al => new { al.AddressId, al.OwnerId, al.OwnerType });

    // 配置Address与AddressLink的一对多关系
    modelBuilder.Entity<AddressLink>()
        .HasOne(al => al.Address)
        .WithMany(a => a.AddressLinks)
        .HasForeignKey(al => al.AddressId)
        .OnDelete(DeleteBehavior.Cascade);
}

优点：

• 完全灵活，支持地址共享，新增实体无需修改Address类
• 可标记地址的具体使用场景，便于业务区分

缺点：

• 查询地址需通过中间表，增加查询复杂度
• 需要手动维护OwnerType和AddressUsage字段，易出现拼写错误

推荐选择 #

• 如果是一个实体对应一个专属地址的常规场景，优先选方案1，逻辑简单、维护成本低，符合关系型数据库设计规范。
• 如果需要频繁新增带地址的实体，且希望Address类保持稳定，选方案2，但需梳理好现有实体的继承结构。
• 如果有地址共享的业务需求，再考虑方案3。

内容的提问来源于stack exchange，提问作者Nuvolari