Устаревшая база данных, с которой я работаю, использовала такой шаблон, как
CREATE TABLE [Document](
[ID] [bigint] IDENTITY(1,1) NOT NULL,
[EntityTypeID] [int] NOT NULL, -- Tells us if the document is for a item, person, company....
[EntityID] [bigint] NOT NULL, -- Is the primary key value from the item, person, company table
[Url] [nvarchar](1024) NULL,
)
В таблице документов не определен FK, поскольку каждая запись может описывать данные, относящиеся к другой родительской таблице.
Пример:
Таблица документов
Таблица лиц
Таблица элементов
Стол компании
Скажем, идентификаторы EntityTypeID определены как Person = 1, Item = 2 и Company = 3. Тогда
Document.ID 1 and 2 are Dave's documents
Document.ID 3 and 4 are documents about Headphones
Document.ID 5 are documents for Acme
Document.ID 6 are documents for Globlex
Моей первой мыслью было создать представления для PersonDocument, ItemDocument и CompanyDocument. и в OnModelCreating сделайте что-то вроде
modelBuilder.Entity<PersonDocument>(entity =>
{
...
entity.HasOne(d => d.Person).WithMany(p => p.PersonDocument).HasForeignKey(d => d.EntityId);
...
}
Это работает для чтения данных и заполнения моих классов DTO, но я не знаю, смогу ли я обновить или создать новые записи документов, используя этот подход.
Когда я пытаюсь добавить документ, я получаю
The entity type 'PersonDocument' is not mapped to a table, therefore the entities cannot be persisted to the database. Call ToTable
Как мне справиться с этим?
Отвечает ли это на ваш вопрос? Как можно представить наследование в базе данных?
Вы можете смоделировать это как Table-Per-Hierachy с универсальным типом, о котором я писал в других ответах. Дайте мне знать, если вы хотите, чтобы я покопался и нашел пример.





на мой взгляд, вам лучше иметь таблицу документов и иметь таблицы, в которых указано, к какому документу это относится (PersonDocumet, CompanyDocumet, ItemDocument), чтобы вы могли иметь контроль.
когда вы вставляете данные, шаг 1: вставьте в документ, затем вставьте в другую таблицу
Документ: Идентификатор, URL
Документ человека:
идентификатор документа, PersonID
КомпанияДокумент:
идентификатор документа, Идентификатор компании
ТоварДокумент:
идентификатор документа, ID товара
Мы собираемся создать таблицу для каждого маршрута объекта. Существует всего около дюжины таблиц, использующих эти «полиморфные ассоциации».
Поскольку вы работаете с устаревшей системой, вам необходимо убедиться, что существующая функциональность остается неизменной. Лучше иметь отдельные таблицы для каждого типа документа, хотя это может быть сложно для управления существующими данными. Другой способ справиться с этим сценарием — отдельные методы для вставки/обновления, связанные с (PersonDocument, CompanyDocument и ItemDocument), и вам необходимо вызывать методы, применяя бизнес-логику.
В прошлом я много боролся с этими полиморфными ассоциациями. Мой окончательный вывод: создайте таблицу для каждой сущности.