Полагаю, вы могли бы сделать это: создать производную таблицу, используя ваши известные значения, и просто присоединиться к ней в качестве вашей соединительной / ассоциативной таблицы.Хотя вместо этого я бы сохранил это в таблице для большей гибкости и простоты обслуживания в долгосрочной перспективе.
Примечание. Такой подход исключает необходимость перекрестного соединения.Вы можете выполнить перекрестное объединение и исключить те записи, которые находятся в другом наборе
SELECT A.Animal, B.Fruit
FROM A
INNER JOIN (SELECT 1 as Animal_ID,1 as Fruit_ID UNION ALL
SELECT 1, 2 UNION ALL
SELECT 2, 1 UNION ALL
SELECT 2,3) Derived
on A.ID = Derived Animal_ID
INNER JOIN B
on Derived.Fruit_ID = B.ID
Если вам нужно сохранить перекрестное объединение (низкая производительность на больших таблицах), тогда это может сработать ...
SELECT A.Animal B.Fruit
FROM A
CROSS JOIN B
WHERE not exists (SELECT 1
FROM (SELECT 1 as Animal_ID,1 as Fruit_ID UNION ALL
SELECT 1, 2 UNION ALL
SELECT 2, 1 UNION ALL
SELECT 2,3) Derived
WHERE A.ID = Derived.Animal_ID
and B.ID = Derived.Fruit_ID)
Однако вам может быть лучше хранить количества, которые не совпадают, в зависимости от объёмов таблицы с течением времени.
Оба эти подхода подходят к значениям HARD CODE.Как правило, это первый признак того, что разработчик делает что-то не так.В очень редких случаях значения должны быть жестко закодированы;вместо этого сохраните их как переменные в таблице, что обеспечивает гибкость изменений без изменений кода.