实体框架核心上下文中Fk的命名

Luc*_*uca 2 mapping naming entity-framework foreign-keys entity-framework-core

我正在开发 EF core 2.2 Rest api 项目。我使用 dbfirst 方法和“Scaffold-DbContext”命令创建了模型和上下文。

模型和上下文有效,但我注意到在上下文代码中,外键有显式名称:

    modelBuilder.Entity<TrackingPoints>(entity =>
    {
        entity.HasKey(e => e.IdPosition);

        entity.ToTable("myTable");

        entity.Property(e => e.CaseId).HasColumnName("CaseId");

        entity.HasOne(d => d.IGeoPosition)
            .WithMany(p => p.TrackingPoints)
            .HasForeignKey(d => d.IPositionId)
            .OnDelete(DeleteBehavior.ClientSetNull)
            .HasConstraintName("FK__Track__iGeoP__278EDA44");
    });
Run Code Online (Sandbox Code Playgroud)

(实际表有更多字段,但我保持简短)

我关心的是 FK 名称 (HasConstraintName)。实际上,这段代码包含有关表之间数据关系的信息,但它也有 FK 约束的显式名称。

我注意到,在该数据库的不同实例(开发、预生产...)中,相同的约束具有不同的名称。

我想知道是否必须在数据库的所有实例上为 FK 约束指定相同的名称,或者尽管约束的命名不匹配,映射是否仍能完美地工作。在开发环境中它可以工作,并且 FK 名称与模型中的名称相匹配。在不同的环境中,第一次测试是可以的,但我不知道命名问题是否会产生一些模糊且难以发现的副作用。

Iva*_*oev 5

约束/索引名称是物理关系数据库映射的一部分,并且对于代码优先迁移很重要,以防迁移需要删除约束。如果名称不匹配,它将无法删除它,整个迁移可能会失败。

如果您继续使用数据库优先方法,并在数据库更改时重新构建(或使用某些外部工具更新)上下文,则约束/索引名称不会对 EF Core 行为产生任何影响。

如果在将来的某个时候您决定切换到代码优先迁移,就会出现问题。因此,尽管对于您当前的工作流程来说并不是非常必要,但在所有数据库中保持名称相同会​​更安全。