Структура сущности:Условный внешний ключ

Question

У меня есть следующая схема в базе данных:

• БиллингСсылки (Тип ссылки крошечныйинт, Идентификатор ссылки крошечныйинт, Тип ссылки крошечныйинт, Идентификатор ссылки крошечныйинт, Активен кусочек) — где все поля (кроме IsActive) являются частью уникального индекса.
• Тип биллинга (идентификатор типабиллинга крошечныйинт, Имя варчар(50))

ReferencingType и ReferencedType — это внешний ключ BillingTypes.BillingTypes содержит следующие строки:

Billingtypeid | Имя

1 | Ярлыки

2 | Страны

3 | Платежные провидеры

4 | Варианты оплаты

5 | банки

ReferecingId и ReferencedId представляют собой идентификатор одного из следующих объектов (зависит от типа ссылки/ссылки):

• банки (Идентификатор банка крошечныйинт, Имя варчар(50))
• Страны (Идентификатор страны крошечныйинт, Имя варчар(50))
• Этикетки (Ид метки крошечныйинт, Имя варчар(50))
• Поставщики платежей (ИдПлатежногоПровидера крошечныйинт, Имя варчар(50))
• Варианты оплаты (ИдПлатежаОпции крошечныйинт, Имя варчар(50))

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

Существует связь (1-) между каждым субъектом (кроме стран) и странами.Метки имеют соединение (1-) банкам, поставщикам платежей и вариантам оплаты.И у PaymentProviders есть соединение (1-*) с PaymentProviders.

Так, например, если я хочу связать банк с Bankid 201 с страной с 3003 CountryId, у меня будет запись в BillingReferences, которые будут выглядеть так:Ссылка

Мы не создавали таблицу соединений/ссылок для каждого типа соединения из соображений расширяемости. Если мы хотим добавить еще одну сущность, все, что нам нужно сделать, это добавить ее таблицу и добавить записи для нее в BillingReferences и BillingType.

Проблема в том, что я не могу настроить условный внешний ключ между BillingReferences и каждым из объектов, и я также не могу настроить/сопоставить его с помощью EntityFramework...

Мне не удалось найти ни одного руководства или примера, использующего этот тип реализации.Обязательно ли мне создавать справочную таблицу для каждого соединения или есть ли способ настроить это с помощью EntityFramework?

Спасибо за помощь :)

Answer 1

AFAIK, нет способа сделать это.

Я бы создал отдельную таблицу для каждого типа, если только у вас нет веских причин не делать этого.Соображение, о котором вы упомянули, не очень хорошее, ИМХО.

Наличие большего количества таблиц ДЕЙСТВИТЕЛЬНО позволяет вам накладывать ограничения внешнего ключа на ваши ключи, и это прекрасно преобразуется в EF.Это также помогает производительности:ваша большая справочная таблица с миллионом строк потребует больше времени для запроса, чем более мелкие таблицы (если только вам ВСЕГДА не нужны все ссылки для типа).

Answer 2

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

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

Answer 3

Единственный способ добиться того, что вы хотели, — это создать триггер для обработки обработки на стороне сервера.Вы не можете сопоставить такие FK с несколькими таблицами.Но триггер может справиться с этой логикой.Конечно, это было бы совершенно за пределами EF...

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

Answer 4

Что ж, думаю, я воспользуюсь предложением Inferis и создам отдельную таблицу для каждого типа.

Спасибо ребята за ваши ответы - они помогли МНОГО :)

Answer 5

В SQL вы можете создать представление для каждого типа на основе одной таблицы.Каждое представление может выполнять соединения для получения информации, относящейся только к этому типу.это также позволяет вам думать о ссылках как о целом, игнорируя их тип.