У меня есть таблицы A и B. У меня также есть ассоциативная таблица A_B, в которой хранятся отношения между таблицами A и B. В таблице A есть записи, которые я хочу связать со всеми записями в таблице B (даже записи, которые можно добавить в будущем).
Пусть говорят, что у меня A1, A2, A3 и B1, B2 и B3.
Я хочу, чтобы A1 был связан с B1 и B3
A2, связанный с B1 и B2
A3, относящийся ко всем Bs
Тогда таблица A_B будет выглядеть так:
A1, B1
A1, B3
A2, B1
A2, B2
A3, B1
A3, B2
A3, B3
Если я добавлю B4, мне нужно будет добавить новую запись в таблицу A_B, чтобы связать ее с A3. Как я могу определить, что "A3 относится ко всем Bs", не требуя таблицы A_B? Я думал добавить флаг в (boolean is_related_to_all), но я думаю, что это выглядит неправильно (я могу в итоге получить сотни is_related_to_all = false)
Есть ли способ сделать это, используя отношения?
РЕДАКТИРОВАТЬ
Чтобы добавить немного больше контекста:
Таблица A хранит партнеров и веб-сайты магазинов таблицы B. Некоторые партнеры связаны с конкретными веб-сайтами, а некоторые партнеры связаны со всеми веб-сайтами (и некоторые партнеры могут не иметь отношения к какому-либо веб-сайту).
Я бы предложил другой подход к решению других решений. Рассматривая проблему с более абстрактной точки зрения, у вас есть два "подкласса" A: те, которые связаны с одним или несколькими B (пусть называют их A_relatable), а те, которые всегда связаны со всеми B (пусть называют их A_related). Поэтому я предлагаю представить вашу ситуацию с пятью отношениями:
A(attributes of A)
B(attributes of B)
A_relatable (only primary key of A as foreign key, also primary key)
A_related (only primary key of A as foreign key, also primary key)
A_B(foreign key of A_relatable, foreign key of B)
Таким образом, все ограничения могут быть проверены, и вы можете определить несколько хранимых процедур, чтобы упростить управление данными.
Ну, если эта мысль слишком странная - не возражайте против нее, но вы можете опрокинуть ее наоборот. Вы могли бы использовать таблицу A_HASNOT_B (более интеллектуальное имя). Таким образом, новые записи в B всегда будут привязаны ко всем записям от A. Вам просто нужно будет инвертировать пользовательский выбор на основе UX перед сохранением отношений.
Таким образом, в вашем сценарии будут следующие записи:
A | B
=======
A1 | B2
---+---
A2 | B3
В зависимости от вашего сценария /usecase это может быть либо элегантным, либо полностью глупым. Если в итоге у вас будет только несколько отношений, это плохое решение, в этом случае я бы выбрал решение (триггер). Если вы считаете, что большинство записей типа a будет присвоено типу b, это может сделать работу очень простым способом.
Вы можете рассмотреть триггер на таблице B:
DELIMITER ;;
CREATE TRIGGER relate_all_b_to_a3
AFTER INSERT ON B
FOR EACH ROW
BEGIN
INSERT INTO (A_B)
VALUES ('A3', NEW.B)
ON DUPLICATE KEY UPDATE B=B;
END;;
DELIMITER ;
Если вы добавите Boolean, это больше не будет традиционным много: множество таблиц сопоставления. Вероятно, FOREIGN KEYs
больше не будут работать.
Но вы, безусловно, можете его кодировать, однако вам нужно будет иметь специальный код a la:
if flag is set, do ...
else do ...
Это может превратиться в UNION
двух SELECTs
. Или это может превратиться во что-то другое. (Я не могу предсказать, не понимая использование этой таблицы сопоставления.)
Между тем, те партнеры, которые не связаны ни с одним веб-сайтом, вероятно, могут быть обработаны, если не оказаться в таблице вообще. (Это может потребоваться 3-е, если /then и/или UNION
.)