Обходной путь для нулевого значения в составном ключе ядра EF

#c# #entity-framework

#c# #entity-framework

Вопрос:

Я пытаюсь использовать ядро EF для доступа к существующей базе данных, которую я не могу изменить. В базе данных есть две основные таблицы для ведения журнала: log и logentry .

 //Log 
LogPK  UserFK  LogDescriptionFK  LogTableFK  PrimaryKey  Stamp

//LogEntry
LogFK  LogTableFK  LogEventFK  LogColumnFK  PrimaryKey  Parm1  Parm2

  

Ни в одной таблице не определен фактический первичный ключ.

Когда пользователь обновляет запись в системе (т. Е. person), Создается одна запись журнала и создается запись журнала для каждого поля, которое было частью изменения (т.Е. Имя изменено с ‘Ted’ на ‘Tedd’, фамилия изменена с ‘Harris’ на ‘Harrison’ и т. Д.).

Все LogEntry записи привязаны к одной Log записи. Записи журнала также привязаны FK к списку имен таблиц, типов событий и имен столбцов. (Я думаю, возможно, идея заключалась в том, чтобы ограничить, какие изменения регистрировались, на основе таблиц и столбцов, которые существуют в этих таблицах).

Первоначальный создатель системы также использовал эти таблицы для регистрации входа пользователя в систему. В этом случае он создал бы единую запись журнала с одной записью журнала. Однако в этом случае «столбец» не изменяется, поэтому значение LogColumnFK равно нулю.

Первоначально я настроил свой DbContext следующим образом:

 builder.Entity<LogEntry>().ToTable("logentry")
  .HasKey(l => new {l.LogFK, l.LogTableFK, l.LogEventFK, l.LogColumnFK });
  

Это отлично работает для регистрации изменений, но когда я пытаюсь войти в систему пользователя, я получаю сообщение об ошибке, потому LogColumnFK что равно null . Удаление l.LogColumnFK из определения ключа должно устранить проблему с регистрацией входа пользователя, но создаст ошибку при попытке регистрации изменений, поскольку элементы LogColumnFK изменений уникальны.

Есть ли какой-нибудь способ обойти это?

Комментарии:

1. начальная база данных с постоянной записью, которая будет использоваться для каждого случая, когда вам нужен FK, но у вас его нет?

2. Я изучаю это — просто не уверен, разрешено ли мне это делать на данный момент. Я надеюсь, что существует технический обходной путь, который позволит мне двигаться вперед без необходимости добавлять «фиктивную» запись столбца.