#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. Я изучаю это — просто не уверен, разрешено ли мне это делать на данный момент. Я надеюсь, что существует технический обходной путь, который позволит мне двигаться вперед без необходимости добавлять «фиктивную» запись столбца.