EF Отображение таблицы на иерархию

Question

Пытаясь нормализовать схему базы данных и отобразить ее в Entity Framework, я обнаружил, что в конечном итоге может быть несколько таблиц поиска.Они будут содержать только пары ключ и значение.Я хотел бы объединить их в одну таблицу, которая в основном состоит из двух столбцов «Ключ» и «Значение».Например, я хотел бы иметь возможность получить адреса Addresses.AddressType и Person.Gender для одной и той же таблицы, но при этом обеспечить, чтобы свойства навигации возвращали только строки, применимые к соответствующей сущности.

EDITОй.Я только что понял, что пропустил этот абзац:

Это похоже на проблему типа TPH, но все прочитанное мною указание указывает на то, что вы начинаете с полей в родительской сущности и переносите поля внаследственные дети.У меня нет полей для перемещения здесь, потому что обычно их будет только два.

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

Есть ли способ представить такую ​​структуру в EF4?Или я лаю не на том дереве?

РЕДАКТИРОВАТЬ: я думаю, что другой вариант будет построить структуру таблицы, которую я хочу на уровне базы данных, а затем написать представления поверх этого и представить их как объекты EF.Это просто означает, что любое обслуживание необходимо выполнять на нескольких уровнях.Это звучит более или менее желательно, чем чистое решение EF?

Answer 1

Таблица на hiearchy требует, чтобы у вас был один родительский объект, который используется в качестве базового класса для дочерних объектов. Все сущности отображаются в одну и ту же таблицу, и существует специальный столбец дискриминатора, чтобы различать тип сущности, хранящейся в записи базы данных. Как правило, вы можете использовать его, даже если ваши дочерние объекты не определяют никаких новых свойств. Вам также нужно будет определить первичный ключ для вашей таблицы, иначе он будет обрабатываться как объект только для чтения в EF. Таким образом, ваш стол может выглядеть так:

CREATE TABLE KeyValuePairs
(
  Id INT NOT NULL IDENTITY(1,1),
  Key VARCHAR(50) NOT NULL,
  Value NVARCHAR(255) NOT NULL,
  Discriminator VARCHAR(10) NOT NULL,
  Timestamp Timestamp NOT NULL 
)

Вы определите сущность KeyValuePair верхнего уровня со свойствами Id, Key, Value и Timestamp (установлены как фиксированные режимы параллелизма). Дискриминатор столбец будет использоваться для отображения наследования.

Имейте в виду, что отображение EF является статическим. Если вы определите объекты AddressType и Gender, вы сможете использовать их, но вы не сможете динамически определять новый тип, такой как PhoneType. Это всегда потребует изменения модели EF, перекомпиляции и повторного развертывания приложения.

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