Всем привет.
Возникла такая задачка:
Нужно связать два типа контента следующим образом:
ТК Инструмент (ТК1), должен иметь какие-то принадлежности - ТК Принадлежности (ТК2). Например «Перфоратор1» имеет «Сверло 1», «Сверло2», «Сверло3» и т.д. Здесь проблем нет, все связывается.
Но и наоборот, принадлежности из ТК2 могут относится к разным инструментам из ТК1. Т.е. «Сверло3», также подходит к «Перфоратору2» и «Перфоратору3»
Такое вообще возможно? Если кто-то решал, прошу поделится знаниями.

Я смутно понимаю, что можно как-то «перевернуть» ситуацию. Вопрос скорее о том как это все удобно сделать для пользователя. Что применить для выбора записей одного ТК внутри другого

Посмотрите здесь - http://old.sebloders.ru/forum/33-obshchie-voprosy/5215-odna-statya-v-neskolkikh-kategoriyakh#11681
Это, в принципе, стандартная задача о принадлежности одной сущности сразу нескольким. Обратно задачу разворачивать не нужно, это никак не добавляет понимания.
В примере поясняется, как разместить ТК "Статья" сразу в нескольких ТК "Категория".
У Вас - ТК "Сверло" нужно разместить ("связать") с ТК "Перфоратор".
Что применить? В "Перфоратор" - мультиселект из ТК "Сверло".
Ну а далее обычный List.

Форум у нас какой-то не очень активный. Подкину дровишек.
dimsco пишет: Задача ставилась сделать взаимную связь данных из ДВУХ ТК (но можно сделать и для записей одного ТК).
Причем 1) связываются только те записи которые нужны и 2)связь записи из ТК 1 с записью из ТК 2 приводит автоматически к обратной связи.
Пример на кошках сверлах:
Перфоратор1 (ТК1) -> сверло 1, сверло 3, сверло 5 (ТК2)
Перфоратор 2 -> сверло 2, сверло 3, сверло 4
Создаем связь, находясь в ТК1, видим под каждым перфоратором список из сверел ( у каждого по 3)
Открываем сверла, видим:
Сверло 1-> Перфоратор 1
Сверло 2 -> Перфоратор 2
Сверло 3 -> Перфоратор 1, Перфоратор 2
Под каждым сверлом видим список перфораторов, для которых они подходят
Решено созданием ТК3, которое пишет в свою таблицу значения ID из ТК1 и ТК2. Ну и извлекаем в List'ы

Поскольку движок наш использует БД MySQL в общем случае, то связь многие-ко-многим стандартно решается, конечно же, введением таблицы связи ключей. Иного, за редким исключением не дано.
В вашем случае ТК3 не нужно, это ж просто общая внешняя таблица.
Так что все же задача стандартна, имеет несколько решений, в зависимости от требований к производительности.

dimsco пишет: Ну, что мне нужно в моем случае, это вопрос не для обсуждения.
А вот интересно было бы (и не только мне) ваше решение этой задачи, без использования ТК3
Как говорится - больше мнений хороших и разных