для раскрытия - запрос проходит сверху вниз - от родителя к ребенку.

В каком случае нужно наоборот? более одного ближайшего родителя? То есть - когда может понадобится весь родительский путь от последнего элемента иерархии?

Чет я не нахожу таких потребностей
Попробую объяснить проще.
1работа
2работа постоянная
3работа проектная
4работа удаленная
5Частичная занятость
6 Постоянная занятость

Получаются ветки
1.2.5
1.3.5
1.4.5
1.2.6
1.3.6
1.4.6

Так вот в каком случае может понадобиться найти от последних элементов всех родителей? Не просто - потому что может понадобится.

Конкретный пример, кто может привести?

  `id` int(6) NOT NULL auto_increment,
  `word` varchar(63) default NULL,
  `parrent_ids` text NOT NULL,
  `children_ids` text NOT NULL,
  PRIMARY KEY  (`id`)

Кстати, одноуровневых связей в этом случае вполне хватает.
По точному вхождению слова "язык", внучатый элемент "языки программирования для винмобайл" будет добавлен и в список дочерних, и наоборот.

То, что я привела выше - это знакомая всем конструкция, я же хочу нумеровать все элементы массива каждого не используя уникальных идентификаторов. Есть связи 1.2, 1.3, 1.4

И есть номер каждой связи. И есть идентификаторы массивов.
Массив 1 может содержать три элемента, два из которых связанны с одинаковыми массивами, а третий со вторым массивом.

используя одинаковые идентификаторы - то есть определяя одни и те же связи для разных массивов мы значительно уменьшим количество связей, и накладывая связи элементов на связи массивов - выбрать детей не затруднительно.

Михаил, если я вас правильно поняла - у вас ведь тоже вхождение от родителя к ребенку?

Наоборот не используется?

ладно соглашусь. Но у меня стоит другая задача и для нее я не нахожу необходимости искать всех родителей.

Это рубрикатор для определения параметров объявлений.

При добавлении объявлений указываются параметры в некоторых массивах из которых сформирован путь к объявлению. Так что найти по сути можно.

Но есть и необязательные параметры в которых связь не определена.

И вот сижу и думаю - на какой фиг мне может понадобится искать всех возможных родителей объявления?, если есть промежуточные?

думаю, вполне возможная потребность - поиск возможных веток к родителям. так называемые "хлебные крошки" или "breadcrumb trails". При потребности подняться на один уровень выше, если родителей больше одного, это действие становится неоднозначным. а значит если что-то такое будет нужно, то и поиск вверх по дереву тоже потребуется.

У хлебных крошек - а они организуются при выводе - у них уже будет идентификатор. Отправляется идентификатор и выбираются все его дети.
В чем неоднозначность?

Я просто хочу избежать простыней связей по которым делается вывод, когда прописываются все связи для дублей. А для параметров, где выводы массивов неоднократно повторяются - это неоправданно большое количество записей.

Что касаемо самого объявления, то к нему и так будут приписываться все параметры которые ему определил пользователь при добавлении объявления. Пара ID массива и значение/

И именно введение нового параметра как ID массива позволит при выводе формировать уровни на лету - не записывая все связи в таблицы.

Я все пытаюсь свои 60 тематических направлений уместить в одной базе.

В том то и дело, что если допустим хочешь ты себе штучку с мультимедийным интерфейсом и еще не определился, с моделью Получаешь родители массивы, которые могут подгрузить перечень производителей и потом будешь искать дальше.

Но зачем тебе знать сами связи между элементами в массиве? Сами связи жестко не прописаны. жестко прописаны только связи массивов.

каждый массив это параметр.

Как по твоему ты будешь записывать параметры, по которым товар был добавлен в таблицу? по ветке? Допустим, да если каждый последний идентификатор уникален мы можем к каждому товару приписать только один идентификатор, по которому мы и определим к чему он относится.

Как + можно определить по одному единственному ID, остальные параметры его, вернее не параметры, а значения параметров

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

По твоему. sony> мультимедиа, panasonic> мультимедиа это разные ветки и у мультимедиа в разных ветках разные идентификаторы, в противном случае мы просто не сможем определить именно ту самую уникальность значений параметров

А у тебя при выводе , опять же для удобства поиска выводятся массивы.

производители и экраны отметил пользователь несколько производителей и выбрал мультимедиа, вывод то элементов массива мультимедиа/не мультимедиа в единственном экземпляре, а по твоим уникальным параметрам в ветке - как определить, к каким родителям принадлежит твое мультимедиа? вывод то элемента мульмедиа единичный. Следовательно нужно делать ID синхронизации, между мультимедиа в разных ветках.

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

Хоть как не пляши а путь и значения определены как параметры к товару при добавлении.

Просто есть пустые параметры, которые и не позволяют определить ветку полностью. Ну не захотел пользователь указывать цену, а другой указал.

Но при помощи ID массива можно сформировать связи между параметрами и знать какие параметры какому товару принадлежат.

Так вот. Здесь затык в пустых элементах массива, потому и не определяется полный путь, но это не значит,что не определяется путь по элементам по которому объявление добавлялось.

За то такой подход позволяет формировать связи при выводе налету

Хотя пустому параметру тоже можно присвоить определенное значение и тогда ветка будет читаться полностью.
Нл это не решает основной проблемы, которой я пытаюсь избежать. Колосального количества записей при жестком ссылочном наследовании дублей по ветке - элемент - элемент.

Мне нужно втулить 60 тематических направлений и каждый со своими параметрами.

И одни и те же параметры могут использоваться в других тематиках.

Например массив мероприятия. Это и кастинги, и аккредитации и билеты.

Конечно, может я слепая - может кто ткнуть носом когда в данной задаче может понадобиться жесткая ссылочная ветка для определения всех родителей от последнего элемента ветки?