Именование Fk в базовом контексте Entity Framework

Question

Я работаю над проектом 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");
    });

(фактическая таблица имеет больше полей, но я оставляю ее короткой)

Меня беспокоит имя FK (HasConstraintName). На самом деле этот код содержит информацию о взаимосвязи данных между таблицей, но также имеет явное имя для ограничения FK.

Я заметил, что в разных случаях этой БД (dev, preproduction ...) одно и то же ограничение имеет разные имена.

Я хотел бы знать, должен ли я дать ограничению FK одно и то же имя во всех экземплярах БД или отображение будет работать безупречно, несмотря на несоответствие именования ограничения. В среде разработки это работает, и имя FK совпадает с именем в модели. В разных средах первые тесты в порядке, но я не знаю, может ли проблема с именами создать какие-то неясные и труднодоступные побочные эффекты.

Answer 1

Имена ограничений / индексов являются частью физических отображений реляционной базы данных и важны только для первых миграций кода в случае, если миграция требует удаления ограничения.Если имя не совпадает, оно не сможет удалить его, и, возможно, вся миграция завершится неудачей.

Если вы продолжите использовать подход базы данных с повторным созданием леса (или обновлением с помощью какого-либо внешнего инструмента),В контексте, когда база данных изменяется, имена ограничений / индексов не будут влиять на поведение EF Core.

Проблема возникнет, если в какой-то момент в будущем вы решите переключиться на код первой миграции.Следовательно, хотя это не является строго необходимым для вашего текущего рабочего процесса, было бы безопаснее сохранять имена одинаковыми во всех базах данных.