Как сделать единый составной ключ на разные таблицы?
Есть БД кулинарных рецептов. В таблице рецептов указывается ингридиент и его количество. Ингридиент может быть либо продуктом (молоко, сахар, яйцо, мука и т.п.) или полуфабрикатом (вафельные коржи, кексовая смесь или даже продукт, но конкретного производителя, например, сухие дрожжи такие-то).
Есть таблица полуфабрикатов, есть таблица продуктов. Ингридиентом может быть запись либо из одной, либо из другой таблицы. Пока выхожу из положения так: Есть поле ingridientId и ingridientType (int) - если ingridientType == 1, то считаю, что ingridientId - это ProductId из таблицы Products, а если ingridientType == 2, то считаю, что ingridientId - это semimanufactureId из таблицы Semimanufactures.
Вся отвтственность за отслеживание что и как в данном лучае лежит на разработчике. Хочу это изменить.
Вопрос в том, нельзя ли сделать так, чтобы силами движка самой БД при составном ключе
ingridientType == 1 + ingridientId была связь с таблицей Products, а
ingridientType == 2 + ingridientId была связь с таблицей Semimanufactures
И еще: Если такое все же возможно, то как в .NET должен выглядеть тип (структура) данных? dynamic? Единый предок для наследников ProductType и SemimanufactureType?
Еще как вариант думал сделать промежуточную таблицу в БД Ingridients
Которая содержала бы в себе свой id и внешние ключи на Products (ProductId) и Semimanufactures (SemimanufactureId) c условием, что только одно из полей ProductId или SemimanufactureId может быть не null в одной записи. и в таблице рецептов указывать именно ingridientId
Я бы хранил продукты и полуфабрикаты в одной таблице с дополнительным полем Type. В таблице сохранить только общие атрибуты, а отличия вынести в отдельную EAV-таблицу.
Ваш вариант с промежуточной таблицей тоже неплох, но немного менее гибок, да и внешние ключи на null значения, так себе решение.
Простой
Простой
