Отношения многие ко многим по умолчанию «все»

Question

Отношения многие ко многим по умолчанию «все»

0

У меня есть таблицы 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. Некоторые партнеры связаны с конкретными веб-сайтами, а некоторые партнеры связаны со всеми веб-сайтами (и некоторые партнеры могут не иметь отношения к какому-либо веб-сайту).

TJ is too short 11 дек. 2017, в 17:40

Источник

Теги:

mysql

database

database-design

4 ответа

Ещё вопросы

Renzo · Answer 1 · 2017-12-12T06-00-00.000Z

Я бы предложил другой подход к решению других решений. Рассматривая проблему с более абстрактной точки зрения, у вас есть два "подкласса" 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)

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

Philipp Wrann · Answer 2 · 2017-12-12T06-00-00.000Z

Ну, если эта мысль слишком странная - не возражайте против нее, но вы можете опрокинуть ее наоборот. Вы могли бы использовать таблицу A_HASNOT_B (более интеллектуальное имя). Таким образом, новые записи в B всегда будут привязаны ко всем записям от A. Вам просто нужно будет инвертировать пользовательский выбор на основе UX перед сохранением отношений.

Таким образом, в вашем сценарии будут следующие записи:

A  | B
=======
A1 | B2
---+---
A2 | B3

В зависимости от вашего сценария /usecase это может быть либо элегантным, либо полностью глупым. Если в итоге у вас будет только несколько отношений, это плохое решение, в этом случае я бы выбрал решение (триггер). Если вы считаете, что большинство записей типа a будет присвоено типу b, это может сделать работу очень простым способом.

reaanb · Answer 3 · 2017-12-12T05-35-00.000Z

Вы можете рассмотреть триггер на таблице 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 ;

Rick James · Answer 4 · 2017-12-12T01-16-00.000Z

Если вы добавите Boolean, это больше не будет традиционным много: множество таблиц сопоставления. Вероятно, FOREIGN KEYs больше не будут работать.

Но вы, безусловно, можете его кодировать, однако вам нужно будет иметь специальный код a la:

if flag is set, do ...
else            do ...

Это может превратиться в UNION двух SELECTs. Или это может превратиться во что-то другое. (Я не могу предсказать, не понимая использование этой таблицы сопоставления.)

Между тем, те партнеры, которые не связаны ни с одним веб-сайтом, вероятно, могут быть обработаны, если не оказаться в таблице вообще. (Это может потребоваться 3-е, если /then и/или UNION.)