Структура сущности:Условный внешний ключ
-
03-07-2019 - |
Вопрос
У меня есть следующая схема в базе данных:
- БиллингСсылки (Тип ссылки крошечныйинт, Идентификатор ссылки крошечныйинт, Тип ссылки крошечныйинт, Идентификатор ссылки крошечныйинт, Активен кусочек) — где все поля (кроме 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?
Спасибо за помощь :)
Решение
AFAIK, нет способа сделать это.
Я бы создал отдельную таблицу для каждого типа, если только у вас нет веских причин не делать этого.Соображение, о котором вы упомянули, не очень хорошее, ИМХО.
Наличие большего количества таблиц ДЕЙСТВИТЕЛЬНО позволяет вам накладывать ограничения внешнего ключа на ваши ключи, и это прекрасно преобразуется в EF.Это также помогает производительности:ваша большая справочная таблица с миллионом строк потребует больше времени для запроса, чем более мелкие таблицы (если только вам ВСЕГДА не нужны все ссылки для типа).
Другие советы
Это невозможно сделать не только в Entity Framework, но и в SQL.У вас не может быть внешнего ключа, который ссылается на одну из пяти разных таблиц.
Я думаю, что вместо этого вам следует иметь родительский абстрактный ссылочный тип и создавать подтипы конкретных типов этого родительского типа.Теперь у вас есть только один внешний ключ для одной таблицы.Вы можете выбрать таблицу для каждого типа или таблицу для каждого сопоставления иерархии.Учитывая, что ни в одном из упомянутых вами типов вообще нет специальных столбцов, я бы подумал, что таблица для сопоставления иерархии будет лучшим выбором для вас.
Единственный способ добиться того, что вы хотели, — это создать триггер для обработки обработки на стороне сервера.Вы не можете сопоставить такие FK с несколькими таблицами.Но триггер может справиться с этой логикой.Конечно, это было бы совершенно за пределами EF...
Я бы также рекомендовал вам построить отдельную таблицу для каждого типа.Я думаю, что в долгосрочной перспективе их проще поддерживать.
Что ж, думаю, я воспользуюсь предложением Inferis и создам отдельную таблицу для каждого типа.
Спасибо ребята за ваши ответы - они помогли МНОГО :)
В SQL вы можете создать представление для каждого типа на основе одной таблицы.Каждое представление может выполнять соединения для получения информации, относящейся только к этому типу.это также позволяет вам думать о ссылках как о целом, игнорируя их тип.